Aspnetcore-angular-universal: HMR not maintaining state

[joshcomley]

Hi, once again, this repo is superb, thank you for it! :)

It seems HMR is playing unlike previous experiences I've had of HMR with Angular, although I am unsure if this is due to it being Universal or not.

Normally HMR retains the state, i.e. field values etc. upon each hot replacement, but if you go to the counter page, for example, and increment it a little, then make some text change to trigger HMR, the counter is reset to zero. The same applies on the other pages, clearing text boxes etc.

Is this a bug or is this what I should expect for now?

[MarkPieszak]

Hey @joshcomley, appreciate it! 👍
So previously I was holding State with NgRx and through a trick, reusing that state when HMR occurred to repopulate the Components.

By default HMR automatically loses state, no matter which framework you use, unless you're using something like Redux / State. So yeah, it's default behavior way no worries!

I'm not sure if I'm going to re-introduce NgRx, but I think I'm going to use a much simpler/basic State management system so we can bring back this feature soon! Thanks for reminding me :)

[joshcomley]

Ah OK, thank you for the detailed explanation! If you have an idea of an existing state management system to use, let me know and I might look into doing a PR :)

The Angular Class HMR module works quite well, not sure if it could be plugged in to this or not, but maybe I'll have a dabble - although I imagine that works very differently because it's not catering for Angular "Universal", just plain old Angular.

[MarkPieszak]

Yes that's what I use in most of my projects, Yeah I'd rather introduce that one as it's much lighter weight, and if someone was to use NgRx it wouldn't be much of an upgrade for them.

If you take a look at the 2.x branch you can see how I was doing it previously with a little hmr hack!

[joshcomley]

Nice, I'm guessing it's this ol' commit:

https://github.com/MarkPieszak/aspnetcore-angular2-universal/commit/7d121629b8cc855ff486b46e9296e4c21e8c8a7c

I'll fish around see if I can get it working on the new version. Would save me a tonne of time on an upcoming project!

[JohnGalt1717]

We're experiencing a ton of HMR issues where it's timing out on builds and then disconnecting from the browser and never refreshing. (and it's taking forever with a relatively large project)

Hoping that the vendor split will help this but right now HMR and server side pre-rendering is causing a ton of issues with both debugging and reloading on changes that is killing productivity.

[MarkPieszak]

Splitting and everything should help speed up builds a lot.
I'll see how many other improvements I can get into the build / HMR process today and tomorrow. :shipit:

[isaacrlevin]

@MarkPieszak @JohnGalt1717 I assume we can close this since a lot of rework has been done with bundling

[JohnGalt1717]

As far as I'm aware this is still an issue. It's reloading the entire page. That's better than when this was originally raise which produced errors it still isn't optimal.

[isaacrlevin]

@JohnGalt1717 are you saying HMR is reloading the whole package ala hitting F5?

[JohnGalt1717]

Pretty close. It's reloading 100% of the dom. It isn't reloading the scripts unless they changed.

[isaacrlevin]

@MarkPieszak do you know if this is an issue with JSServices itself?I have seen in the past when HMR kinda breaks if there are some order of ops issue