purescript-flame: cool & well documented alternative Elm like frontend framework
GitHub | Documentation website
Hello everyone! I shamelessly took purescript-hedwig and added more features to make a complete Elm like frontend framework. Including:
- Different ways to handle application events
- Server side rendering (a la React hydration)
- Signals for arbitrary custom events
- Some convenience type classes and functions for the DSL markup
Following the links above, there are plenty of examples and documentation. There is still need of a few polishing touches (like adding benchmarks), but overall it is stable and I am quite happy using it on my own projects (e.g. here).
Posted Apr 3, 2020, 5:55 PM UTC
4010
This looks very nice, and excellent documentation , thanks!
One question on effectful updates. The
Worldupdatefunction uses flatmodels, notmodel -> modelupdate deltas. So suppose I have two simultaneous Aff operations, each of which should update a different part of the model when they complete. How should I express that, without the second operation to complete overwriting the result of the first one?Thanks!
Yes, there is nothing fancy about
World.update.Since the order of asynchronous operations is not guaranteed, you'd have to collect all results before updating the model (or thread it sequentially).Update deltas do seem an interesting idea, however. Do you have any suggestions here? As far as I know, it works the same in Elm (regular updates/using
Cmd.batch).[deleted]
Ohhh... sorry, I think I completely misunderstood the API. I think everything is good.
In the
Worldupdatefunction, themodelis just the synchronous updated model, and themessageis what is sent later asynchronously, right? The similarity with the normalupdatefunction made me think themodelwas a future value too.Sorry for the noise! I look forward to trying this out.
Yes, the World functions should work the same as raising a new message (perhaps the naming/docs could be more clear?:).
Your suggestion does make a lot sense if someone tried to call World.update in some non deterministic way (e.g with Control.Parallel). But I think actually removing it from the API is the better thing to do -- granted it is 1am but I can't think of an operation that couldn't be performed directly since it is on the Aff monad.
Actually, I think I read it correctly originally, and it seems a bit problematic. The entire model does get reset to its value back when the Aff operation was started, plus whatever changes are initiated only by that operation.
For example, take your affjax sample, and stick an extra `Aff.delay` of a few seconds in the request, to give some more time. If you kick off the request, and then quickly type some characters into the input box, then when the reply comes back, the input box gets reset to the contents back when the Aff operation was started.
It seems more intuitive/useful to me if this worked differently. eg there wasn't a `model` parameter to the `World.update` function at all, just a `message`, and the library provided the most recent value of the model to the user's `update` function. Does this make sense?