React Hotloading in native Meteor is ready (i.e. no webpack)

jasongrishkoff · February 8, 2016, 8:51pm

This looks really cool. Have been tearing my hair out with slow reload times on the client side. But, I’m a little confused with this step of the installation:

Symlink babel-compiler-hot, ecmascript-hot, hot and modules-runtime (#6) to your app’s packages dir.

Can you provide a little more clarity? Should I be doing step 1 (the git clone) in the root of my project directory?

tgoldenberg · February 8, 2016, 9:01pm

I was praying for this today! Seriously, this is huge

tgoldenberg · February 8, 2016, 10:41pm

Getting this error while trying to load - While loading plugin 'compile-ecmascript-hot' from package 'gadicc:ecmascript-hot': module.js:338:15: Cannot find module 'mongodb'

gadicc · February 9, 2016, 10:24am

And we’re in Atmosphere!

See the README for updated installation instructions.

@jasongrishkoff, @tgoldenberg - this should solve your issues I hope

tomRedox · February 9, 2016, 10:36am

Hi @gadicc, the ReadMe on Atmosphere says this:

Until we publish to Atmosphere:

git clone https://github.com/gadicc/meteor-react-hotloader
Symlink babel-compiler-hot, ecmascript-hot, hot and modules-runtime (#6) to your app’s packages dir.
and then:

Edit your .meteor/packages and replace ecmascript with gadicc:ecmascript-hot
In project root, npm install --save react-transform-hmr

Is that still the correct installation procedure or is it now just a case of doing meteor add gadicc:ecmascript-hot to get it working?

gadicc · February 9, 2016, 10:42am

No I realized that after I already finished publishing. See the project README. The one in Atmosphere will be updated on my next publish, I didn’t want to bump versions and republish just to update the README there…

So yeah no need for the git clone anymore. You can indeed do meteor remove ecmascript and then meteor add gadicc:ecmascript-hot@0.0.1-modules.7, or just reflect this in .meteor/packages.

arunoda · February 9, 2016, 11:46am

Do this:

meteor publish --update

It will update just the README.

gadicc · February 9, 2016, 12:26pm

Oh wow, lol… thanks!

benjamn · February 10, 2016, 11:55pm

This is really awesome! If you want to keep working on it, I’m happy to share my thoughts. I would love to see something like this in 1.3.1.

Here’s one thought: https://github.com/gadicc/meteor-react-hotloader/issues/3

I also see you submitted https://github.com/benjamn/install/pull/6, which I would like to avoid if there’s any other way to do it, but I’m sure we can figure something out.

mordrax · February 11, 2016, 11:22am

Loving this where it works, but it doesn’t seem to hot load all of my files, what am I doing wrong?

I get this error:

Opened issue here:

github.com/gadicc/meteor-hmr

"X.js is not hot" on root and relative paths.

opened 10:20AM - 11 Feb 16 UTC

closed 04:42PM - 13 Feb 16 UTC

mordrax

bug

I'm running a downgraded (from beta.8) beta.7 and I can get my pure components t…o hot reload which is **awesome!** However, I'm hitting this issue when importing from a file which just exports some JSON data. What am I doing wrong? ![image](https://cloud.githubusercontent.com/assets/4709169/12973811/6deb59aa-d103-11e5-90ab-0b549ec0606d.png) ``` javascript import React, {Component, PropTypes} from 'react'; import cotw from '/client/modules/enums/enums'; import {connect} from 'react-redux'; import actions from '/client/modules/actions/index'; class AttributesView extends Component { render() { let { attributes, onChangeAttribute, cotw } = this.props; return ( ... <div className="label">{cotw.getAttributeDescription(attribute.name, attribute.value)}</div> ... ) } const Attributes = connect( (state) => { return { attributes: state.player.attributes, cotw } }, (dispatch) => { return { onChangeAttribute: (attr, val) => { dispatch(actions.setAttribute(attr, val)); } } } )(AttributesView); ```

gadicc · February 12, 2016, 10:00am

Thanks, @benjamn!

Yes, please do share your thoughts. I had planned to discuss the way forward with you after a 1.3.0 final came, once things have calmed down a bit. If you’d like to do so before, let me know your preferred medium (we could open an issue on meteor/meteor to track the various subissues involved, etc).

As per the README, this current solution is “hacky by design” (which has been quite liberating). It’s also not a full HMR implementation, but just the bare minimum needed for the react hotloading to work. However, if you’d like this to serve as the basis for something official, I can gradually move to something more structured where possible (e.g. full HMR runtime on the client, with tests, etc; modifying the build process in the “right way” might be beyond me though).

Will reply to the other github issues directly.

gadicc · February 13, 2016, 4:45pm

Hope people have been enjoying this! Unfortunately since I’m using pre-release version numbering I can’t track downloads on Atmosphere.

I’ll also be a bit more pro-active at announcing version updates here, since a few annoying things got fixed recently. The current version is gadicc:ecmascript-hot@v0.0.3-modules.7 and you can see the changelog in the 2nd post of this thread or on github.

The two most important recent changes are better module resolution (we didn’t support root and some relative paths until now), and an automatic full client refresh for cases we can’t handle (so no need to manually restart Meteor, which was annoying). You can also trigger this by hand by just typing hot.reload() in the console now, if desired.

Top priority moving forward is better recognition of stateless components, and cases where hotloads fail when they shouldn’t (and we need your help here to report them). A longer term goal is to provide full HMR support (not just for react), which will allow redux and other hotloading too.

But most important is feedback. Is this working well for you? When isn’t it? Reporting issues on github is the only way annoying things will get fixed.

P.S. I’m away for a few days again and am travelling after, but I’ll find time to squeeze in small fixes here and there.

jasongrishkoff · February 13, 2016, 9:07pm

Hi there. On this point:

Edit your .meteor/packages and replace ecmascript with gadicc:ecmascript-hot@0.0.2-modules.7 (don’t forget to set it back before a production deploy!)

How do you propose handling that if we’re using the Atmosphere package? Must we “meteor remove gadicc:hot” before doing our Mup deploys?

mordrax · February 14, 2016, 3:08am

I imagine you’d just toggle the comment on both lines no?

//.meteor/packages
#ecmascript
gadicc:ecmascript-hot@0.0.3-modules.7

gadicc · February 14, 2016, 7:17am

@jasongrishkoff, yeah sorry, you no longer need gadicc:hotin your .meteor/packages file. Since the Atmosphere release, gadicc:ecmascript-hot implies gadicc:hot too, to make for a super simple replacement.

I too recommend just toggling the comments like @mordrax suggested, before deploy. If you prefer using the meteor CLI, that’s fine too, but then you should also meteor add ecmascript after removing ecmascript-hot. Hopefully in the future we can come up with a good way to avoid the need for this.

Last note, looks like I didn’t update the README properly, the current latest version is indeed 0.0.3.

mquandalle · February 14, 2016, 4:17pm

I have not tested it so I don’t know if it works but maybe you could use a condition on process.env.NODE_ENV on the gadicc:ecmascript-hot package.js file?

Package.onUse(function (api) {
  api.versionsFrom('1.3-modules-beta.7');

  if (process.env.NODE_ENV === 'production') {
    api.imply('ecmascript');
  } else {
    // current code: `imply`, `addFiles`, `export`...
  }
});

mquandalle · February 14, 2016, 4:22pm

Hum unfortunately process.env.NODE_ENV is undefined in package.js. Is that on purpose @benjamn?

gadicc · February 14, 2016, 5:17pm

I think it is. Meteor relies on package.js to build the package to be published, making conditional logic problematic. I know we used tricks like this often in the past but as far as I know package bundling is handled differently for a while now.

mordrax · February 18, 2016, 10:39am

Had to interrupt my flow and share this. (tl;dr - This package is the sh!ts, why are you not using it already in 1.3?)

So I was doing some massive refactoring because due to some brain-spasm, I had introduced ES6 classes into my redux state which was causing all sorts of refresh issues as I modified internal properties.

JS being the unfriendly, untyped monster it was caused everything to break left right and center as I jiggled around my states to normalize them, reordered my reducers, removed classes etc etc… My chrome dev console was throwing errors, Max stack limit reached, cannot hot reload x.js and others. But I persevered knowing that my goal was within sight.

Lastly, I came to hooking up the init state so I could test by hitting any route on a refresh:

  let areas = generateAreas();
  cotwStore.dispatch({type: "INIT_AREAS", areas});

The moment I typed the last ;, hit <enter> and Ctrl+S, my browser which had constantly been blank and flashing errors in the console suddenly sprang into life and my game map was BACK!

I lost the plot.

The workflow with hotloading has been amazing. It almost instantly refreshes react component changes and also does a full refresh on all other file changes. I don’t know why but a full refresh with hot loading is also faster, taking on average ~2sec with the error appearing in the console.

Normally, I’d be waiting 5-10 secs for meteor to build on each compile/debug/test loop.

Adoration over, back to coding…

spherop · February 19, 2016, 12:03am

After following install instructions I get:

W20160218-15:34:03.513(-8)? (STDERR)
W20160218-15:34:03.514(-8)? (STDERR) /Users/dpnewman/.meteor/packages/meteor-tool/.1.1.13-modules.7.ip1bjg++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20160218-15:34:03.515(-8)? (STDERR)            				throw(ex);
W20160218-15:34:03.515(-8)? (STDERR)            				      ^
W20160218-15:34:03.602(-8)? (STDERR) Error: locals[0] does not appear to be a `module` object with Hot Module replacement API enabled. You should disable react-transform-hmr in production by using `env` section in Babel configuration. See the example in README: https://github.com/gaearon/react-transform-hmr
W20160218-15:34:03.602(-8)? (STDERR)     at proxyReactComponents (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules.js:21750:11)
W20160218-15:34:03.602(-8)? (STDERR)     at meteorInstall.both.lib.authorizeForRole.jsx (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/app/app.js:59:59)
W20160218-15:34:03.603(-8)? (STDERR)     at fileEvaluate (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules-runtime.js:219:9)
W20160218-15:34:03.603(-8)? (STDERR)     at require (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules-runtime.js:92:20)
W20160218-15:34:03.603(-8)? (STDERR)     at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/app/app.js:12405:1
W20160218-15:34:03.603(-8)? (STDERR)     at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/boot.js:242:10
W20160218-15:34:03.603(-8)? (STDERR)     at Array.forEach (native)
W20160218-15:34:03.603(-8)? (STDERR)     at Function._.each._.forEach (/Users/dpnewman/.meteor/packages/meteor-tool/.1.1.13-modules.7.ip1bjg++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160218-15:34:03.603(-8)? (STDERR)     at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/boot.js:137:5
=> Exited with code: 8