Thanks for the thoughtful response, Gary! I have an idea of how to implement that sort of explicit state retention, so yeah, I know what you mean and how it’s different from having something that JustWorks™.
Hot reloading + state is a bit of a concern for me, as popular libraries like Vue and React have it out of the box, and it’s very widely used. So now this is another annoying point against PureScript + Halogen that I’ll have to deal with (I’m assuming HMR+retaining state probably works fine with PS + React bindings).
Also, hot reloading’s ubiquity is what allowed Tailwind CSS to become popular: if you can change component markup without having to reload, it’s then possible to iterate quickly through design changes. Personally I dislike Tailwind, but I have to admit it’s very popular, and a large number of developers will disregard Halogen because they won’t be able to use it or tools like it.
By the way, I’m just saying this to be informative, not demanding!
We’d have to impose a constraint that all component state is serializable through some means, and also I think it would probably not behave in an ideal way - it would probably have to throw out some or all of the state if the serialized version no longer matched the state schema for the components.
My feeling is not ideal is better than nothing. In Vue, for example, there are rules regarding state preservation. Those rules can be a bit finicky:
This also means you need to be careful about global side effects such as timers inside your components lifecycle hooks. Sometimes you may need to do a full-page reload if your component produces global side-effects.
I read this is as, ‘Lolle actually you’ll need to press F5 sometimes!’ And yet, the appeal you mentioned seems to outweigh the problems with it.
Without thinking about it too much, I also feel like PureScript — with its strict separation between pure and effectful functions, and its type system — might be capable of doing a better job at HMR+retaining state than React or Vue.
