dmjio 1
27 Likes
This new avatar of miso is simply marvellous to look at.
I am not a frontend developer (tried my hand at elm and enjoyed it, but haskell I enjoy more)
this has me intriguiged enough to try one more time .. this time with miso
A question though.. what’s the limitation here?
Can we do something like what reactflow allows for react.. ?
2 Likes
dmjio 3
thank you
In theory we should be able to make a miso-flow version, xyflow has a framework agnostic core called xyflow/system that we could wire up to miso’s virtual DOM nodes using onCreatedWith lifecycle hooks. I might give that a try, others have asked about that as well.
1 Like
dmjio 4
Dear @kushagarr ,
Was able to get Claude Fable to scaffold out an integration between xyflow/system and the miso DSL. I am not an xyflow internals expert, but this seems like a decent start that could be iterated upon.
example: [https://flow.haskell-miso.org](https://flow.haskell-miso.org)
example code: [miso-flow/example/Main.hs at master · haskell-miso/miso-flow · GitHub](https://github.com/haskell-miso/miso-flow/blob/master/example/Main.hs)
haddocks: [https://flow-haddocks.haskell-miso.org](https://flow-haddocks.haskell-miso.org)
repo: [GitHub - haskell-miso/miso-flow: Node-based UIs for miso, powered by xyflow · GitHub](https://github.com/haskell-miso/miso-flow)
2 Likes
Thanks for another release! I’m working on a project now and chose Miso over Elm and I’ve been very happy with it.
I’ve been using global context to follow patterns I learned back with some React work with Reflux and later native context, though it’s more of a dispatch pattern than setContext. Is the global context just message passing under the hood, or does it work directly on specially available data?
I’ll also have to explore this new aeson option. One point of friction has been having two JSON libraries between client and server and it became a mess when I tried to unify on Miso due to some differences between my GHCJS and regular packages in NixOS. Maybe it’s time to take another look.
1 Like
dmjio 6
Awesome, would love to see your app.
Is the global context just message passing under the hood, or does it work directly on specially available data?
The latter, context is shared by all Component in a global IORef. Whenever it is modified (via modifyContent in update) the scheduler thread will update the IORef and redraw all Component whose useContext = True (any Component that was mounted with mountWithContext) top-down.
I’ll also have to explore this new aeson option
The new -faeson -ftext flags will polyfill Miso.JSON as Data.Aeson and force type MisoString = Text on the client. That was requested by users that are integrating with other libraries on the client that make heavy use of text / aeson, for ergonomic reasons.
Otherwise, type MisoString = JSString is the default, and Miso.JSON uses JSString for the String constructor. This was shown to be the most performant configuration for the JS backend in general, for WASM backend it seems to vary by workload.
Unfortunately, it’s an admin-only data-management UI at the moment for pages served directly from Servant right now, so hard to demonstrate. Also, it’s still under development and I can’t say I’d necessarily be proud of it at this point.
context is shared by all Component in a global IORef
I’ll definitely look into this new context mechanism then. There’s some nice abstractions to message passing and creating a single owner of data, but it’s just annoying to manage. Context-management functions can easily be centralized for 95% of the benefit but an IORef will just be simpler and more efficient. Less async nonsense to deal with too.
Ah, so the Aeson in this case is more of a client-side thing and not server-side. Sounds like it’s not particularly useful in my case of unifying server/client logic. I don’t see a reason not to use native JSON on the client.
Thank you for the awesome project!
1 Like