georgefst
commented
5 days ago Of course, many solutions to this problem are pretty hacky and unsound. I don't think any of the JS frameworks or bundlers implementing hot reloading (often referred to as "HMR" - hot module reloading, presumably since modules are the smallest unit replaced) have a great story around what happens when interfaces change in incompatible ways.
But Miso is potentially in a great position to handle this in a principled way, since everything is immutable and the state is a first class entity. It even has a type, so we can detect when changes are incompatible. All we need to do is serialise the state on each update (or on exit, if we can reliably intercept that) and attempt to de-serialise upon reloading*. Come to think of it, this still isn't really true hot reloading, since the code is fully replaced, but it's much simpler and the end result is largely the same.
A hacky working prototype, probably with race conditions, is as simple as:
startAppWithSavedState :: (Eq model, Read model, Show model) => Miso.App model action -> JSM ()
startAppWithSavedState app = do
loadedInitialState <- liftIO $ doesFileExist filePath >>= \case
False -> pure Nothing
True -> readMaybe <$> readFile filePath
startApp
app
{ model = fromMaybe app.model loadedInitialState
, update = \case
Nothing -> pure -- no-op
Just a -> \m -> do
m' <- first Just $ app.update a m
m' <# do
liftIO $ writeFile filePath $ show m'
pure Nothing
, subs = mapSub Just <$> app.subs
, view = fmap Just . app.view
, initialAction = Just app.initialAction
}
where
filePath = "miso-state"Various potential improvements:
- [ ] Use
binaryoraesoninstead ofRead/Show(or evenforeign-store?). - [ ] Write to a path in
/tmpor somewhere rather than the working directory. - [ ] Strip out the extra logic when compiling to JS/WASM.
- [ ] Maybe modify the actual definition of
startAppinstead of wrapping it. This would avoid the mess of usingMaybe actionas the actual action type just to get a no-op action to accompany writing the output. - [ ] Somehow detect when the state type has changed in a way that can be trivially adapted, such as the removal of a constructor which is unused by the current state, or even the addition of fields with
Defaultinstances. This might be easiest if we serialise to JSON. - [ ] If writing the state on every single update is slow, then just do it when the page is about to be closed ("beforeunload") or maybe navigated away from ("visibilitychange").
- [ ] Provide some mechanism for the user/developer to manually reset the app to the initial state.
* I'm hardly the first person to notice this. This Elm article talking about how much easier the whole problem is in a functional setting is over a decade old. Unfortunately, it's also presumably out-of-date since it mentions FRP. I don't know what support for hot reloading Elm has today.
dmjio
The sample app README mentions "hot reload". Perhaps these terms aren't all that standardised but my experience from the JavaScript ecosystem is that what we have in the examples, via
jsaddle-warp'sdebugfunction, where the browser auto-refreshes but state is reset, is called "live" reloading. Whereas "hot" reloading tends to mean actually swapping out code without restarting the program, as associated with languages like Lisp, Erlang and Smalltalk.As far as I can tell, Miso doesn't support this?