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

Reversed Hot-Replacement #1138

Open
theKashey opened this issue Dec 21, 2018 · 2 comments
Open

Reversed Hot-Replacement #1138

theKashey opened this issue Dec 21, 2018 · 2 comments
Milestone

Comments

@theKashey
Copy link
Collaborator

theKashey commented Dec 21, 2018

parent issue: #1121
is an action for: #1024

There are huge problems updating Class-based components. We fight with them for a year, and look like there is only one way to defeat them - surrender.

How it works currently

  • RHL set prototype from a new class to an old class
  • As long as the class constructor could not be "updated" or "redone" we have to "find" updates manually
  • RHL creates new and old classes, looks for differences (not all of them are visible)
  • overrides class variables to replicate changes on the real instances (not all changes are replicatable) using eval injected by the babel plugin to maintain the "variable scope" (which might be wrong)

In short - it lands some important "changes" from hot-updated code to the existing ones. Maintaining the state just because it is not updated. The result could be far from reality.

  • the prototype-based methods are all "new", they are all right
  • any other method update is )transported_ from a new (variable) scope to an old one
  • some operations, performed in a constructor, could not be redone and skipped

Proposal

  • create a new component from a scratch, as we are doing
  • detect any difference between the old component and instance, as we are going
  • inject all changes we want to keep to the new instance
  • replace old instance by a new one on fiber level.
  • update refs if they existed (probably could be done on createElement level)

In short - keeps some important changes, like state or lifetime variables. The result is a reality, the same as if you refresh a page.

This is actually a refresh, but with a state kept (and we don't need anything else)

The only difference - we should inject a new instance deeply to react-dom.

  • 👍 react 16 only

  • 👍 babel plugin is not required, as long there is no need to inject updated code to existing classes.

  • 👍 any third party code, like react-redux should be hot-reloadable without any change from their side.

  • 👍 no more type comparison problem

  • 👎 react-🔥-dom is required

It might be a blocker. The more we patch sources of react, the deeper we are in trouble. This this proposal is something, that should be done, I am not sure that it's something, that could be done.

@theKashey
Copy link
Collaborator Author

Superseded by #1261

@theKashey
Copy link
Collaborator Author

#1261 does not solve class reloading problem, this idea is still valid and required.

@theKashey theKashey reopened this Jun 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant