JSPM/SystemJS live-reloading hot-swapping dev server? #1
Comments
|
Just changed post-css.js to use the Needed this because I need to guarantee the order in which CSS is requested is preserved (previously it was the order of responses). It's all working though! |
|
GOT REACT HOT LOADING WORKING
It's a pretty rough hack right now (it assumes you're using ES6, only exporting a default class, named a certain way, etc) but it ACTUALLY WORKS :) I ended up just copying the current The complication comes from the fact that react-hot-loader needs to wrap itself around every definition of a React class, even the first one (not just after the first new version appears). But I couldn't figure out how the plugin might be able to inject something in between the Anyway, I think this is a big win, I'm very excited about where this leads. Zero-configuration virtually instantaneous reloading with JSPM is a pretty awesome concept. Particularly if we can standardise on a way that plugins can be live-reload friendly 😀 |
|
@geelen, really nice work here! what APIs would help make this easier? It seems like:
Glad to hear the plugin hook chaining works well. Is there anything I can do to help further? |
|
@guybedford: +1 for this feature. @geelen what can be done at this point to help out with the implementation of live-reloading hot-swapping? |
|
Let me publish where i'm at. I have my postcss plugin and my jsx plugin.
|
|
Published! Check out instructions on https://github.com/geelen/typeslab and see jspm-server in action! |
|
Oh and yeah you can do |
|
Hi everyone, I did try the typelabs project as is, I also tried integrating the all stuff in my own projet but I can't get the jsx files to hot reload... It does a full reload whenever I change a jsx file. Standard javascript files are correctly hot reloaded though. any idea ? |
|
ok nevermind I forgot to add the |
|
Hey @johnraz, I'm actually in the middle of changing how the live-reloading works, so the current version jspm-server doesn't automatically work with TypeSlab any more. It should be fixed in the next couple of days, but adding that snippet should get you some of the way in the mean time. |
|
Ha ! Automatic hot reloading is possible then ?! That would be super awesome! |
|
@geelen I wonder, can you explain how hot-reload works without any plugin ? I just hit btw is there any better solution than pushing code per component? Many thanks! |
|
@asaf : you do need a custom plugin for the So this is solving the "pushing code per component" for the react components. Its not the case for the regular es6 modules though, and it would be nice to have a way to make them automatic too. Regarding all the dependencies related to hot reloading, those are installed in the target project itself not in jspm-server, there is no way afaik that it would work if not installed in your target project. |
|
It could be worth allowing load metadata as an alternative way to indicate hot reloading as well (and that would also avoid the export * issue for hot reloadable modules as well if that causes problems down the line). That would allow something like: System.config({
meta: {
'*.js': { hotReload: true }
}
}); |
|
That could be a great solution @guybedford. I think hot-reloading should be opt-in, but yeah, it would be good to not to have to specify it on each and every file... |
|
I created a new issue to keep talking about this - will make the discussion stands out for newcomers and we will be able to reference it once fixed ;-) |
|
Any update on this? |
Ok, this is me just starting an issue to discuss with @guybedford about where this might fit in to the JSPM landscape. It didn't seem ready to add something against jspm-cli or systemjs yet because it's really early days, but I do have something working and I'd like to get feedback.
This project is a fork of live-server which I've been using for all my dev with JSPM. It has the best collection of defaults I've seen for any 0-configuration server, and doesn't build upon tiny-lr or anything, so I found the code really easy to get going with (thanks @tapio!)
Anyway, on to the proof-of-concept!
The main change from live-server is the behaviour here, where now I'm actually passing through the paths of the files that change, rather than deciding whether to 'reload css' or 'reload the whole page' on the server.
That logic has now moved into ChangeHandler, which uses
System._loader.modulesto figure out what's been loaded, and what plugin it used. It then loads the plugin and sees if a flagreloadableis set. Since my CSS plugin uses a side-effect to insert the CSS into<head>, I can simply callSystem.load(with a cache-busted URL) and cause the CSS to be reloaded.Of course, I had to actually set my plugin up to work that way: post-css.js. I've changed this now to only ever add one
<link>tag to the HEAD, but use a Map (which is ordered) to keep track of the source files so far loaded. When any new ones are translated, add them to the map (if they haven't been seen before they'll go at the end, if they have they'll take their older version's place) and regenerate the one<link>tag with a new URL. This means you can define variables in one file and use them in another, sincepostcssis being called on the full concatenated source each time.In the end, I got a lot further than I thought I would have, because live-server had done so much already. Designing my CSS plugin to handle updates wasn't too bad, and actually bought me that variable support between two imports: defined with this import then used with this one
All in all, this server + plugin combo gives me super freaking fast CSS feedback, which was the whole goal. I'd love to extend this to support React hot-reloading too, but I understand that a lot less at the moment.
What do you think? Is there a better way to figure out what's loaded than
System._loader.modules? And a better way to force a reload than using a cache busting query-string?The text was updated successfully, but these errors were encountered: