I'm building an app with InstantDB (workflow very like Firebase; tangentially it's really awesome!) and have so far been using Helix to build it directly in React with hooks. but there's some parts of this app that are absolutely crying for the greater structure and local state management that Fulcro offers. I can't find an example of integrating with Firestore (or OG Firebase), so while the docs make it clear that it should be possible, I'm not quite able to connect the dots. I can write an EQL parser that will compile subtrees of The Query into InstantDB queries, but they create subscriptions that will fire callbacks when things change on the server. what I can't figure out is when exactly I should subscribe and unsubscribe to those queries.
Well, you obviously know when you want to add/remove a subscription, right? Like from a high level. Nobody else would really know. Such things are usually tied to two issues: • What’s on screen • Side-band data that might be of interest to the user for other reasons (e.g. notificataions) Personally, I’d design such a system with statecharts, and use on-entry and on-exit handlers to manage the subscriptions, while also integrating the routing concern with states. I’m actually working on some expansions of my statecharts library that help with this, but there’s nothing particularly difficult about the concept, I’m just having trouble getting time to finish my design there…but you could easily just adopt the general ideas and code it up yourself.
My experimental project is here: https://github.com/fulcrologic/fulcro-with-statecharts
The basic idea is to create special state wrappers (i.e. rstate and istate, demonstrated here https://github.com/fulcrologic/fulcro-with-statecharts/blob/main/src/main/com/example/client.cljs#L169) that associate visible routes with states, and possibly invoke nested statecharts (istate = invoking state).
where then a child statechart can be co-located on a component like this: https://github.com/fulcrologic/fulcro-with-statecharts/blob/main/src/main/com/example/client.cljs#L103
This gives you full compositional power, with great expressiveness. The statechart wrappers like rstate are just that, are are easy to make yourself. They’re just functions that do some boilerplate:
https://github.com/fulcrologic/statecharts/blob/integration-improvements/src/main/com/fulcrologic/statecharts/integration/fulcro/ui_routes.cljc#L99
I’m building up these elements exactly because I think it would be a great way to build applications, where there is often not enough cohesion of the sometimes complex coordination issues that applications need (people spread the logic in ways that is hard to follow). This also happens to match your use-case nicely, in that making your own special kind of “subscription” state that on entry/exit manages your firebase seems a great match.
that does sound like a great fit! you're right that I know where I want to put the subscriptions, but I couldn't find the right "edges" to hook up subscribing and unsubscribing. I think the statecharts style would likely be helpful for this app even aside from the subscription model. even at this early prototype stage, there's a future/present/done/cancelled pipeline, and an invite flow that are obvious fits for state machines.
thanks for the detailed links! I'll try it out and see where I get. I'll aim to separate concerns and build up my UI based only on state machines and in-memory data (or IndexedDB or whatever) for now. the magic of decoupling means I don't have to care about everything all the time.
At the moment some of the code I linked above is on branches and is unreleased. But like I said, it is just building on stuff I already had in place, so you should be able to follow it.
From there when you get your data updates your best friend is merge-component! in Fulcro, which can take the incoming data and normalize/merge it into the db (refreshing the UI).
The big “new” add is getting away from dynamic router altogether, where I’m managing the routes and state initialization with the statechart. That’s a big change from stock Fulcro.
Right now I’m sidetracked with a rewrite of Fulcro Inspect to deal with Chrome manifest v3. I’ve gone a bit off the rails on that, and it’s taking a lot longer than I wanted.