Edit your react components and see changes instantly, while maintaining state.
Note: the implementation is hacky by design. The idea is to bring react hot loading to Meteor today, and give us / MDG more time to work out the best way to do this in the long term (see e.g. this post).
Haha I left out the repo link on purpose, it’s not really ready for use yet. I’m back next week and will finish things up for a proper release. But I did make a few tiny fixes in the mean time for the eager beavers (In that case, let me know your experiences…)
Also, just to clarify, it’s more than “faster reload times”. The client doesn’t reload at all; only changed code is injected into the client, respecting modules, and updating (proxied) react components so they stay mounted and keep their state! (This last part is the work of the amazing @gaearon / dan abramov as in webpack and is a massive time saver for development! Think about not needing to re-open dialogs, select options, etc, after saving.)
@goatic, even though this isn’t “the right way”, so far it seems to work really well! With a bit more time I’ll be able to say exactly where this will and won’t work. But at the most, for stuff we can’t do, we’ll simply force a real refresh like before.
Thanks @arunoda for the kind words Besides Mongo, the hacky stuff is how we trick Meteor’s build process to not refresh, bypass the linker, and totally hack modules-runtime :> But it’s working super smooth so far. I’ll also mention that I plan to officially support MantraJS patterns.
@imkost In sublime3, color scheme is “Packages/Babel/Monokai Phoenix.tmTheme” (via the babel package). I don’t have a font specified in my user settings, so I guess it’s the system Monospace font which I’ve set to Liberation Mono. I’m using the Infinality font patchset for rendering (with the regular archlinux font settings recommendations).
I’m not 100% sure what the final recommendations will look like. Actually, the example in the screencapture is using ReactDOM.render… so I guess this will be supported too I just need to do a bit more research into the best way to trigger everything, and ran out of time… I think I know though, so expect more next week :>
The thought behind that choice is that React is going outside of the DOM. You can render to native, to your toaster, soon ReactKitchenSink.render will be a real thing.
So they’ve extracted it to ReactDOM because it only renders to the DOM.
Does it make sense? Yes. Is it cludgy? Maybe? I don’t know.
I think we can work on this. I suggest you to open a issue on Meteor’s github and I hope we will have a way to do it a less hacky way. This is a really important project.