Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Controlled type comparison #74

Closed
wants to merge 1 commit into from
Closed

Conversation

theKashey
Copy link

@theKashey theKashey commented Oct 29, 2018

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
Copy link
Collaborator

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 [email protected]. Thanks!

@facebook-github-bot
Copy link
Collaborator

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

React.compareControl( (typeA, typeB) => typeA === typeB ? typeA : null)

// threat any components with the same name as the same
React.compareControl( (typeA, typeB) => typeA.displayName === typeB.displayName)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

gaearon commented Dec 4, 2018

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants