You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The major part of RHL is to understand how one can replace the old code, by the new. Currently, we have a quite approach:
in case of babel - register all top-level variables.
in case of webpack - all exported variable.
Each time React will try to update any component, not from this list - it will re-render tree, and you will get a state lost.
So HOC, decorators, functional compositions - you are drunk, go away. For many-many people, this is just blocker, and we have to solve it.
PS: State loss is not a problem. Mount/Unmount is a problem.
I've spiked possible solutions from many directions and got a one, which may work.
Move react tree traversal from react-deep-force-update to react-hot-loader, and perform an update by comparing the old and the new tries. It does support onUpdate/shouldUpdate now, but does not expose position inside a render tree.
One old tree and the new tree should be the same, if some node got another set of children - you have to purge the old one in any case. But for RHL cases trees will be same, and in case of more global update HRM will update the whole page.
So the algorithm is simple:
Update the code.
before update traverse the old tree.
Call render method of a first Component. Fetch part of an old tree and try to find similarities.
3.1 In case of named-components match - easy. It is ok - update proxies and go deeper.
3.2 In case of named-components mismatch - easy. You can go deeper with state loss.
3.3 In other cases try compare source code of components. If it is same - it is mostly safe to update proxies. Look like even having 100500 components with the same source code, but with the different scope variables, it will work fine.
....
Profit.
This will fill the gaps between registered components and fix RHL :)
Look like it could work. @neoziro, I saw some crazy tree-traversal stuff in react-loadable, so could you leave few comments?
The text was updated successfully, but these errors were encountered:
The major part of RHL is to understand how one can replace the old code, by the new. Currently, we have a quite approach:
register
all top-level variables.Each time React will try to update any component, not from this list - it will re-render tree, and you will get a state lost.
So HOC, decorators, functional compositions - you are drunk, go away. For many-many people, this is just blocker, and we have to solve it.
PS: State loss is not a problem. Mount/Unmount is a problem.
I've spiked possible solutions from many directions and got a one, which may work.
Move react tree traversal from react-deep-force-update to react-hot-loader, and perform an update by comparing the old and the new tries. It does support onUpdate/shouldUpdate now, but does not expose position inside a render tree.
One old tree and the new tree should be the same, if some node got another set of children - you have to purge the old one in any case. But for RHL cases trees will be same, and in case of more
global
update HRM will update the whole page.So the algorithm is simple:
3.1 In case of named-components match - easy. It is ok - update proxies and go deeper.
3.2 In case of named-components mismatch - easy. You can go deeper with state loss.
3.3 In other cases try compare source code of components. If it is same - it is mostly safe to update proxies. Look like even having 100500 components with the same source code, but with the different scope variables, it will work fine.
This will fill the gaps between registered components and
fix
RHL :)Look like it could work. @neoziro, I saw some crazy tree-traversal stuff in react-loadable, so could you leave few comments?
The text was updated successfully, but these errors were encountered: