Open gampleman opened 3 months ago
Another thing to consider would be potentially asynchronously initializing. Some applications must perform effects before they can be properly started (even the good old Time.now
, it's annoying having to actually store that as a Maybe
or need to also provide a flag for that).
I guess something like a "applicationWithLoader" would do the trick. The loader part would be a mini-app with its own state and view, that has the goal of building the Shared state. I will think about it.
Hey @gampleman , Could you give PR #18 a try and give me some feedback? Thanks
Looks pretty good, I'll try to use it in our app tomorrow/next week and see how it works in practice.
On a slightly separate note, I wonder if something like this API sketch would be a useful abstraction for this (if you added flags decoding to it of course).
Most non-trivial apps need to decode their flags from JSON, but this of course has the property that app initialization can fail if the flags fail to decode properly.
One can of course mitigate this by making their shared type into something like:
but this gets annoying, since we need to deal with pattern matching on this shared type everywhere in the application and basically we don't really need the rest of the application if it fails to initialize, since the only thing we can do is show some sort of error screen.
I would then suggest to change
Spa.application
(or make a new version of it if backwards compatibility is a concern) to something like:This would then present the
errorPage
on flag decoding failure. I've found (we had a private fork some time ago) that there is quite a useful feature whereEffect.catastrophicFailure
can be then added that goes straight to theerrorPage
.Another idea to consider would be to somehow recycle the
defaultView
for this purpose, although I'm not confident the type system would quite allow it.