Any way to use an alternative at React hot module replacement?

Tweaking my react component takes very long since each modified bit triggers a complete rebuild. Is there a valid way to to work with a RHMR like?

Take a look at the gadicc:ecmascript-hot package. I don’t think it has been updated for Meteor 1.4.x, but it might help you out regardless.

Thx but Ecmascript hot has some issues which make it impossible to use in 1.4

That shouldn’t be the case - might be a bug in Meteor or in the app configuration. The whole page does reload, but it shouldn’t be recompiling the entire app.

1 Like

Except in the case where components are also loaded on the server, which would be the case if you are doing SSR.

1 Like

My current understanding is that files are compiled incrementally - only the ones that have changed, so given that the server does reload the thing to optimize would be server startup time rather than compilation time.

1 Like

You should be right since this is the major feature of the last Meteor release. But in my case I don’t see a real difference in build time. (I wait about 15 - 20 secondes each times).
Note that I use typescript barbatus:typescript@0.5.2* so the compiler may act differently?

But the real annoying thing is the entire page reload. This is not convenient at all.

For now I am trying story book to find another workflow.

For non-SSR react projects it takes at most 3-4 sec to rebuild client-side on meteor 1.4; If you have a good knowledge over optimising imports, you may try using webpack’s hot module replacement. Though, personally, since 1.4 I find no need in HMR in case, its use cases are rather limited, worthy of 0.5 s advance considering overhead it takes to work with additional builder.

@sashko is right, you shouldn’t have huge rebuild times with correct setup.

20 seconds is definitely not typical. It takes 3 or 4 seconds for my app and it’s getting kind of big.

And are you sure typescript does not add a load of work at build time? I have 97 .ts file (average one module each) and 40 .jsx

3-4 second is for a empty project on my laptop (MBP 2010). Is there a real world test project which I can see such good performance?

Interesting thing, I see at the end of every rebuild log in the terminal =>server restarted
It is so usual that I did not get attention to it but it happens event if I only change a client file (a jsx for instance)

Here is a discussion about HMR:

I see people migrating their front-end to pure webpack and it makes sense. I don’t know what you’re doing that you app rebuilding in 4 sec, in my case it takes about 10 seconds and it’s really annoying when you just change a “font size” and have to wait 10 second on rebuild every time. I have no idea how to implement “design” productively this way.

Any suggestions on rebuilding time optimization? (react, mobx, apollo stack)

Well I am using Storybook now which greatly improves the experience of my design workflow. It is “just” a node plugin which runs a webpack server aside of Meteor. So you could integrate with whatever stack you use.

So I design my React components in storybook (4 second to wait max, so game changing) and the update should automatically be visible in Meteor because I modify the same source file. I say “should” because a bug of React Storybook prevents me to run both Meteor and Webpack at same time.

1 Like