I as a React-Hot-Loader maintainer would like to discuss the expectations for React-Hot-Loader and how it actually should behave.
Keeping in mind React-Hot-Loader(RHL) v4 (current), it does not:
- handle hot module replacement(HMR), and user have to setup it by own hands, even if RHL provides a helper function. Might be RHL have to search react-dom usage, and inject HMR code magically?
- update a component, if a change occurs in life cycle method. Maybe, as long a change in componentDidMount is something, that could affect the “past” of the component, RHL has to NOT hot reload component, and let it unmount, to actually reflect the change.
- handling errors occurred during hot reload. Should we display an Error overlay (possible remounting “broked” component), or better keep error in console, or display error in “another place”(portal?)
In the same time:
- to support untranspiled arrow functions it requires a babel plugin to patch all component-based classes (and eval). Howewer, it could ask a user to transpile arrow function into es5 code and overload .bind method. This might make TS uses much more happier.
- it transforms stateless functional component into the statefull to have an “instance” it could work with, which could affect how code is actually executed. For example someone could not find a “ref” in production. (that is pretty neat)
Anything else, RHL did not do, but you might think - it should.
Anything else, RHL is doing, but you might think - it shouldn’t.