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
RHL and HRM comes together, and HRM fails to reload data - RHL also could not work.
All modern loaders has some assumptions about how to detect HMR:
imported-component - based on PureComponentUpdate (ie someone (RHL) force updated it)
universal-component - based on componentWillRecieveProps (lots of false positive)
loadable-component - just always loads component in dev mode ("deferred" loading is not a thing)
react-loadable - no assumptions
Meanwhile - we could execute the same trick loadable-component uses - just import new file, it will register itself, and next RHL will perform an actual "update".
The idea behind is based on how "module system" works - when you are importing something, you are becoming a parent, for a module you did import. As a parent - you will get HRM events, you may react on.
I could see 2 ways
Add module.accept using babel plugin
constComponent=Loadable({loader: ()=>import('./module')});^^^^^^^^^^^^^^^^^^^^^// then be ready to reload all modules, with ReactComponents registered and used.// not _all_ modules and _all_ imports, only those ones, who could work using RHL.register to update instance.module.hot.accept(''./module',()=>reactHotLoader.hasComponentsFrom('./module')&&import('./module'));
1.1 - we might use statusHandler instead of accept to observe, not to change the code. The same trick we are using in hot HOC.
Create a separated imported file, as react-imported-component does, then track all loaded files, and reload them on HRM.
The major benefit of this way - it creates another module, and accept in that file will work in parallel, not affecting the "real code", ie the cases when you might have "accept" in another place. Probably this is not the case keeping in mind 1.1
constComponent=Loadable({loader: ()=>hotRelodable('./module',import('./module'))});/////
# hot-relodable.js// all the "imports" of project, extracted by pluginconsthotRelodables={'./module': ()=>import('./module')};consthotRelodable=(moduleName,promise)=>{hotRelodables[moduleName]();returnpromise;}module.hot.accept(reloadAllLoadedRelodablesWhichAreComponents)
Second way is a bit more hard to maintain, probably we should go with .1
The only thing we need to impliment - internal tracking of factual usage of some component from some file.
RHL version 1 did something similar, reloading everything by it's own, but everything. I hope that not accepting all possible changes, but only "component-reloading" ones could do things better.
RHL and HRM comes together, and HRM fails to reload data - RHL also could not work.
All modern loaders has some assumptions about how to detect HMR:
Meanwhile - we could execute the same trick
loadable-component
uses - just import new file, it willregister
itself, and next RHL will perform an actual "update".The idea behind is based on how "module system" works - when you are importing something, you are becoming a parent, for a module you did import. As a parent - you will get HRM events, you may react on.
I could see 2 ways
module.accept
using babel plugin1.1 - we might use
statusHandler
instead ofaccept
to observe, not to change the code. The same trick we are using inhot
HOC.react-imported-component
does, then track all loaded files, and reload them on HRM.The major benefit of this way - it creates another module, and
accept
in that file will work in parallel, not affecting the "real code", ie the cases when you might have "accept" in another place. Probably this is not the case keeping in mind 1.1CC #953
The text was updated successfully, but these errors were encountered: