Breaks for some imports about react-hot-loader HOT 9 CLOSED

@gaearon why don't replace React.creactClass with hmr proxy on top of the app? RegExp check is a mess. Even if replace it with a parser like esprima or graspjs the variable name is unpredictable.

from react-hot-loader.

I think it is possible to inject hmr code once in app entry point instead of patching every module. If you don't have time for this I could try to manage the issue and send a PR.

from react-hot-loader.

You can't inject it on top because each module needs its own module-specific createClass function.

You can probably do following:

1. Instead of replacing regex, monkey-patch React.createClass at the beginning of each module
2. Restore React.createClass at the end of each module (otherwise first require in the file will mess it up)
3. Currently we opt out of hot reload for modules that don't have regex matches. If we say goodbye to regex, we must only enable hot reload (if module.hot code) if monkey-patched createClass was called during module definition.

from react-hot-loader.

Confused about point 3. Why need this check if patched createClass will be called explicitly every time we want create a component?

from react-hot-loader.

Modules opt in to HMR by calling module.hot.accept. We don't want to opt-in to HMR for files that contain no components. For plain JS files, it's best to let HMR bubble up dependency tree because for most React apps, there is a component somewhere on the too, and it is HMR-capable by itself. As a consequence, side-effect free plain JS modules will get hot reloading as a bonus by the virtue of being require from HMR-capable components.

However, if we just put module.hot.accept in every file (as opposed to those containing createClass calls), Webpack will think that these files are truly HMR-capable (which they are not), and won't bubble reload up when they change.

Right now we add module.hot.accept when regex matches, but if we do away with regex, we must have other way to know if module is “componentish” or not. One way to do that is to check if monkeypatched createClass was called by the end of module definition. If not, probably this module contains no components, and therefore we shouldn't emit module.hot.accept, or we lose the benefits of HMR bubbling.

Finally, this is only a problem if regular (non-component) files go through this loader. This is often the case. Personally, I use JSX transforms even on plain JS files so I can use Harmony syntax and some JSX occasionally in helpers.

from react-hot-loader.

@mbektimirov

1.0.0-alpha no longer uses the regex. Instead, only module.exports is hot-enabled implicitly.

However, there is an API to hot-enable any class (e.g. a private one, or one inside a function):

var SomeComponent = React.createClass({ ... }); // or ES6 class in the future

if (module.makeHot) {
  SomeComponent = module.makeHot(SomeComponent);
}

from react-hot-loader.

Great, looks much better now. Will you drop components store by displayName?

from react-hot-loader.

Yeah, there's no need for that now.

Now it works like this:

• module.exports is always stored implicitly, regardless of displayName
• call to module.makeHot(SomeComponent) by default uses displayName or name (ES6), but you can specify any other key as a second parameter

from react-hot-loader.

Closing, as this will be available in 1.0.

from react-hot-loader.