es2015-loose preset is now deprecated. You should use es2015 preset as follow according to this:

{
    "presets": [["es2015", { "loose" : true }]]
}

Is there a reason not to use the env key to only load the plugin during dev (like what we used to do with the hmre preset)?

  "env": {
    "development": {
      "plugins": ["react-hot-loader/babel"]
    }
  }

You can totally use it but in this case I added a process.env.NODE_ENV check into the plugin itself so it’s a no-op in prod anyway.

But at least for me, it still gives a warning to the console that "react-hot-loader/patch" did not run immediately before the app started. Is this on purpose?

Are you married to this name? This is very nondescript, vs something like <HotEnabler> or something even more accurate.

In other words, the more root wrappers an app has (<Provider>, styling, themes, etc.), the more this could warrant a clear component name.

I’m open to change it but I want to make it clear it’s an identity component in production and you don’t need to worry about removing it in prod builds. Also, in addition to hot reloading, it takes care of render error handling (currently on mount, and on update after facebook/react#6020 lands).

Please feel free to raise an issue at RHL repo to discuss!

When do you think facebook/react#6020 will land? 15.x or 16.x?

I think 15.1

Any update? :)

To confirm this finally merged in React 15.4.1
Redbox render errors are awesome!
Thank you @gaearon for finally merging this.

AppContainer just renders your root component in production. (Bundling it is not a problem.) In development, it handles hot reloading, and should handle error handling after facebook/react#6020 ships.

why component? why not simply this.props.children?
@gaearon

Filed as gaearon/react-hot-loader#244, would you like to send a PR?

@gaearon Oh, you're responsive. Like my webdesign.
I would maybe, if I could make this whole thing work in my project. Currently when I add the plugin to my .babelrc I get this strange babel-related error:

    tagSource(%variable_name%, '%variable_name%');
              ^

ReferenceError: %variable_name% is not defined

Maybe it's not a bug but rather something in my setup (server-side React rendering on Node.js).
I guess my project is too compicated and egde-cased for trying out v3-alpha.
I'll stay with the hmr plugin for now.

@gaearon Oh, seems that I'm not the only one having this error:
https://gist.github.com/nfcampos/216edf34ae47dfff809df41c58b58c8f

Yes, it’s fixed in 3.0.0-alpha.9.

Worth noting for those experiencing problems (I just figured this out on my own) - no need to wrap your root component in AppContainer on the server side. If you do, it will trigger an error: transaction.checkpoint is not a function. The only reason I tried to do this was so my React checksum wouldn't be invalidated, but turns out that's not even an issue. 😃

Thanks for the info, I filed as facebook/react#6689.
Will probably need a workaround on our side in the meantime.

I just upgraded from 1.3.0 to 3.0.0-beta.5. After updating my webpack config, I ran the dev server without wrapping my root component in AppContainer, and hot reloading still works. Is wrapping with AppContainer still necessary @gaearon? I was surprised it worked at all.

@andy-j-d : I'm wondering how to get this working without AppContainer. In our app, we have multiple entry pages and each one has their own root components (several, in some cases). It would be a huge pain to wrap all of them. Wondering if there is a way to automate it, or just not have to use AppContainer at all

@andy-j-d I have the same question, have you met some problems not wrapping AppContainer, can you share the experience here?

I have to be a better approach then having this in every single entry point.

You have to write this thing yourself. Upside: no more dreaded Error: locals[0] does not appear to be amoduleobject errors in server, test, and other environments!

Would I still be able to use old approach? locals[0] didn't disturb me a lot, since it's described by https://github.com/danmartinez101/babel-preset-react-hmre. On the other hand, I don't want to use yet another React component as a wrapper and duplicate code in entry point.

Would I still be able to use old approach?

You can use babel-plugin-react-transform but I don’t plan any updates to it, so you’re on your own if something breaks there.

On the other hand, I don't want to use yet another React component as a wrapper and duplicate code in entry point.

It is up to you. To me, the benefits of the new approach are that it works great with functional components, and does intrusively rewrite your code. When React lands facebook/react#6020, AppContainer will take care of error display in development too—without any need for tricky wrappers like react-transform-catch-errors which didn’t work for functional components anyway. But again, it’s your call.

my Root is like this, and module.hot.accept doesn't seem to be able to figure out the dynamic dependents we pass in through props.routes. what do we do?

import React from 'react'
import { Provider } from 'react-redux'
import { Router } from 'react-router'

module.exports = (props) => {
  return (
    <Provider store={props.store}>
      <Router history={props.history}>
        {props.routes}
      </Router>
    </Provider>
  )
}

@kunchenguid If you declare routes outside, you’ll need to module.hot.accept them. The whole purpose of extracting <Root> is so the hot update bubbles through the import chain to it, but this won’t happen if you import routes somewhere else.

@gaearon gotcha... should we wrap a AppContainer around everything we module.hot.accept though?

ah i think we can just module.hot.accept the other files, and in the accept callbacks just do the same thing and render the entire Root?

I have a component structure which looks like:
<AppContainer><Root /></AppContainer>

    <Router
      history={browserHistory}
      render={applyRouterMiddleware(useScroll())}
      onUpdate={onUpdate}
    >
      {routes}
    </Router>

where routes is a const, defined above the Router.

I get the following error: Warning: You cannot change <Router routes>; it will be ignored
I'm not sure where to go from here as this message feels somewhat contradictory to the above advice.

@keriwarr I believe you have to turn routes into a function routes() rather than just a variable.

Have you also done the whole <NextApp /> thing?

see my own example app with it working react-lego in particular the react-hot-loader branch

hm. thanks for the comment, but as far as I can tell I am now doing both of those things, and the error persists. Time to dig deeper

I'm also experiencing this problem, AppContainer doesn't seem to play nicely with Router and throws Warning: You cannot change <Router routes>; it will be ignored Can anyone point me to existing example of those two behaving well together?

The error goes away if you add ReactDOM.unmountComponentAtNode(document.getElementById('root')); right before you call render() again. Also fixes a memory leak this original code had

More info here: https://facebook.github.io/react/blog/2015/10/01/react-render-and-top-level-api.html

@fracmak Doesn't unmounting make you lose state? I thought keeping state between reloads was one of the points of hot-reloading.

good point, guess you could always try out React Router v4

Could we get a migration or example implementation that uses a provider? I'm really struggling to get both react-hot-loader's AppContainer component to play nicely with the explicit Redux HMR changes. They both work in their vacuums but seems to cause problems for each other.

@Krustal take a look at this as a solution:
reduxjs/react-redux#502

the http://gaearon.github.io/react-hot-loader/getstarted/ guide, which looks like it has been updated for react-hot-loader 3, has the component as a child. Is this still an option.

Should we install react-hot-loader as dependencies instead of devDependencies?

Since it’s only useful in development, I don’t think so.

Yes, but now AppContainer is "rendered" in the production environment. It needs react-hot-loader to know to fall through, no?

Ah, good catch. Yeah, in this case it would make sense to put it in dependencies. Pull request welcome!

Okay, I create a PR #280.

@gaearon I've kept my react-hot-loader in devDependencies and created a HMR component which either returns the AppContainer or just the children depending on the NODE_ENV. https://github.com/peter-mouland/react-lego/blob/react-hot-loader/src/app/containers/HmrContainer/HmrContainer.js

would that be the preferred solution or is that overkill just to keep the prod dependencies down?

Gotta add this one before any other code runs.

If I use the CLI tool do I need all of these? As in I was planning on using --inline instead of webpack-dev-server entry points you've shown here.

I think --inline will take care of the first two entries, but react-hot-loader/patch is still necessary. You can just put it as the first statement in your entry point, before any imports:

require('react-hot-loader/patch');

or

import 'react-hot-loader/patch'

It’s important that this is the first import, before any other imports.

lot of attempts, use require and import, but anyway i look only that message in chrome devtools:

React Hot Loader: It appears that "react-hot-loader/patch" did not run immediately before the app started. Make sure that it runs before any other code. For example, if you use Webpack, you can add "react-hot-loader/patch" as the very first item to the "entry" array in its config. Alternatively, you can add require("react-hot-loader/patch") as the very first line in the application code, before any other imports.

in my package json there is a script:

"start": "webpack-dashboard --inline --watch -c cyan -- node ./config/dev-server.js",

i'm insert in top of dev-server.js require hotloader as shown below:

require('react-hot-loader/patch')

var path = require('path')
var express = require('express')
var WebpackDevServer = require("webpack-dev-server")
var webpack = require('webpack')
var webpackDevMiddleware = require('webpack-dev-middleware')
...

Technically you can leave react-hot-loader/webpack here if you don’t use Babel or if you use Babel but don’t use ES6 modules. If you use Babel with ES6 modules, removing it is fine.

looks like you can't omit the -loader suffix in webpack anymore:

Module not found: Error: Can't resolve 'babel' in '...'
BREAKING CHANGE: It's no longer allowed to omit the '-loader' prefix when using loaders.
                 You need to specify 'babel-loader' instead of 'babel'.

You can if you add proper patter for loaders resolver. You just need to add this to your webpack config:

resolveLoader : {
    moduleExtensions: ["-loader"],
}