Seb's Deprecation Wishlist Umbrella

[sebmarkbage]

I have a list of breaking changes that I'd like to see because I think they're not strictly necessary features, can often be replaced by other APIs and their very existence makes implementations more constrained, even when they're not used.

This list is not meant to be anything we're planning on actively doing. It's just a drop point where I can add things as I think of them.

• Shallow freeze the defaultProps object and make the defaultProps property non-configurable/non-writable after the first createElement or createFactory call. (Enables inlining/resolution of defaults statically.)

• Treat key/ref as a separate namespace in JSX. Meaning that objects that are spread onto JSX don't transfer key and ref. Enables inlining of props object even if spread type is unknown. E.g.

let x = <Foo {...{key:'bar'}} />;
x.key; // null
x.props.key; // 'bar'
let y = <Foo key="bar" />;
y.key; // 'bar'
y.props.key; // undefined

• Drop support for string refs.

• Drop support for ReactDOM.findDOMNode(...) and ReactNative.findNodeHandle(...). These are slower in Fiber and requires a tree to be materialized/stateful/introspectable at arbitrary times/threads even before we know if this will ever get called. Less automatic cleanup. Could possibly have an alternative API that works more like refs. However, just ref forwarding probably solves all legit use cases better.

• Make .type and .props private on ReactElements so that they can't be introspected (just like bound functions/closures). This makes optimizations like automatic making components asynchronous/synchronous safe or inlining components several levels deep.

[syranide]

Make .type and .props private on ReactElements

Am I understanding this correctly, <a foo="bar">.props.foo will no longer be allowed? Will there be some other way to introspect elements?

[sebmarkbage]

@syranide I think those use cases can typically be solved with the "coroutines" feature. Allowing you to render down to some public API (which could just be the same object as the props object).

[syranide]

@sebmarkbage Ah, didn't know about coroutines. This makes a lot of sense 👍

On a side-note, I'm curious what this means for JSX; is this something that will eventually work itself into the JSX-spec? Which I assume would then have to include some run-time features for unpacking/traversing the elements for renderers. If it's a reasonable end-goal to keep JSX generic that is. Or might it eventually go in the direction of somehow tagging elements with "React" or some other implementation that would have their own *.createElement implementations, i.e. React<div><span /></div>.

[sebmarkbage]

Maybe more like https://github.com/tolmasky/generic-jsx ? The key needs to go somewhere though.

[NE-SmallTown]

These are slower in Fiber

Could you explain more details?

[SavePointSam]

Is there something stopping the ability to drop support for string refs with React 16? Maybe worthwhile to print a warning to provide a clear upgrade path and then fully drop support in React 17.