Transition from react-hot-loader to babel-plugin-react-transform

[tvararu]

TL;DR: https://github.com/gaearon/react-transform-boilerplate.

Dan Abramov has mentioned that he's going to kill react-hot-loader, and that it's being replaced with babel-plugin-react-transform and its ilk.

I've tried it out and not having to deal with "cannot read _currentElement of null" is a big deal™.

[lukekarrys]

Dropping some more links here for when I get time to do this. As of now I think I'll just try and implement the new babel transforms without replacing webpack-dev-server with the webpack-dev/hot-middleware + a custom server.

https://github.com/gaearon/babel-plugin-react-transform
https://github.com/gaearon/react-transform-catch-errors
https://github.com/KeywordBrain/redbox-react
https://github.com/gaearon/react-transform-webpack-hmr

[sansthesis]

One of the side effects of react-hot-loader being deprecated is that gaearon isn't supporting hot reloading some of the new react 14 features, such as stateless functional components:

gaearon/react-hot-loader#198

He's actively working on implementing the same feature in react-transform-hmr at gaearon/react-transform-hmr#6

[HenrikJoreteg]

Yup yup. Thanks Jason, I've been watching this as well and want to switch
as soon as the functional component support is done. This sounded hopeful:
https://twitter.com/dan_abramov/status/653536868324233216

On Mon, Oct 12, 2015 at 11:50 AM Jason Rose notifications@github.com
wrote:

One of the side effects of react-hot-loader being deprecated is that
gaearon isn't supporting hot reloading some of the new react 14 features,
such as stateless functional components:

gaearon/react-hot-loader#198
gaearon/react-hot-loader#198

He's actively working on implementing the same feature in
react-transform-hmr at gaearon/react-transform-hmr#6
gaearon/react-transform-hmr#6

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

[lukekarrys]

One thing I was wondering about is if it is worth it to drop webpack-dev-server in favor of a custom dev server with express like is being done in the new react-transform-boilerplate?

[sansthesis]

I don't know enough to have an opinion on implementation choices; I've just started using react 100% of the time recently and this tool has already helped, so I want to help with it too.

[tvararu]

One thing I was wondering about is if it is worth it to drop webpack-dev-server in favor of a custom dev server with express

That will add in the flexibility of being able to easily hook in other express middleware as well.

Worth considering are how it affects the current experience of bootstrapping a project with hjs-webpack. A custom express server would have to live inside the host project, so you'd have to provide that as boilerplate? Alternatively, you could probably replace npm run start's webpack-dev-server with node ./node_modules/hjs-webpack/server.js, but I'm unaware if that has deeper implications.

[HenrikJoreteg]

@tvararu that can be worked around by creating "bin" files that become commands when installed. So we could just make one up so the user would just replace webpack-dev-server with hjs-dev-server or whatnot.

[dignifiedquire]

Is anyone working on this? Otherwise I should be able to do this either today or tomorrow

[lukekarrys]

That would be awesome @dignifiedquire!

[dignifiedquire]

@lukekarrys I've started, you can track the progress here: https://github.com/Dignifiedquire/hjs-webpack/tree/65-react-transform, first example is working, but still needs cleanup, more testing and migration docs. I hope to get to it tomorrow.

[HenrikJoreteg]

I don't think anyone is, I haven't had the time personally. Happy to have
some help.
On Tue, Dec 22, 2015 at 02:38 Friedel Ziegelmayer notifications@github.com
wrote:

Is anyone working on this? Otherwise I should be able to do this either
today or tomorrow

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

[chrisvfritz]

While replacing react-hot-loader with babel-plugin-react-transform does have many benefits (static analysis FTW!), it also means dropping hot-loading support for any non-Babel users. Just want to make sure that decision is made consciously. Is a focus solely on Babel the direction this project is heading?

Personally, even as someone who much prefers every other compile-to-JS language I've ever used over Babel, this project is focused on React and Babel simply has the best tooling for React development. I don't see that changing any time soon, so I'd prefer the increased focused over wasted development time trying to please everyone (including me).

[lukekarrys]

Closes by #117

[tvararu]

Yay! 🎉