Controlled type comparison

[theKashey]

View rendered RFC

React-Hot-Loader is not yet 16.6 compatible, and no more 16.7 compatible. It could not handle hooks, and would probably break on another stuff in a future.

This is a simple proposal to fix it - just let control type comparison, to stop faking types in a user space, as React-Hot-Loader usually does.

Already implemented in Inferno - infernojs/inferno#1336 (logic is inverted)
Tested with Preact - preactjs/preact#1120

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[brigand]

In one you return ?React.ComponentType and in the other a boolean. Could you clarify?

[theKashey]

That's something I could not decide yet. Which type should be used - a new one, or an old one?
Right now - an old one, always. This is why it could work.
With controlled comparison - it could use a new one. That would mitigate some RHL side-effects.
But sometimes you may render an absolutely another type(proxied by RHL), moving "side-effect" a bit deeper to realization, which also would fix gaearon/react-hot-loader#304

[gaearon]

We generally avoid global configuration like this.

I wonder if it's sufficient to have something like React.lazy but that can take an Observable of module values instead of a Promise. It would always use the latest module type for rendering, but switching the wrapped type to the next one would not reset the reconciliation.

[theKashey]

That would work for lazy, memo or forwardRef, as long as it's possible to maintain ref equality, and change only type it refers to. But not for SFC or Classes - they just simple "direct" refs.

• It's possible to create new container type, to hold ref to a component, but it would break type comparison.
• it's possible to use some sort of wrapper(as we always did), but it would break go-to-code feature of Dev Tools, and type comparison. Plus updating the wrapper is a tricky task for HOCs and friends.
• moving element.type comparison into React does not break anything, plus makes "wrapper" updates an easy task - no need of rendering react-tree by hot-loader.

This RFC was already implemented via webpack-loader to patch react-dom at build-time or separate package to make it simpler - that's literally 2 lines change in React-dom code - https://github.com/hot-loader/react-dom.