ok thanks

You can always make a mutation, and pass the mutation as a parameter in event-data (calling a mutation returns the mutation call as serializable data). Technically, since UISM events are only used locally (won’t need to be serialized), you could just put a lambda in the event data.

The requirement for serializable is “flexible”. I used to stress it a lot because it enables things like a support UI debugger from production and such. I also personally find callbacks messy, so I try to find better ways. But there are times when you just need them. so, if you don’t mind them looking weird in inspect, etc…you can do it.

Aha, I would like to trigger some loads from that callback so maybe having it as 1 mutation symbol is not the best. Unless I do a mutation that triggers loads and additional mutations from ok-action.

why not code the loads into the state machine itself???

Basically I want to decouple “after login” action from the state machine that does login flow

I have some loads I would like to run when user logs in

personally I think your entire session management should be in a machine, and should NOT be decoupled…makes it way easier to follow all the possible branches of sesssion madness mess.

and since they come from all over the app, I didn’t want to put them into login machine

ah

like I wanted to have a successful user login trigger, category load, user data load, other entities that are basis for the menus for the logged in user

Hooks, IMO, are much cleaner when you need to have side-effects coded into a component (where you’d normally use componentDidUpdate, etc). The old-class based methods are a mess. Managing refs, making helpers that need to do some async js thing at the UI layer, etc.

They also made it way better to create things like use-component for Fulcro, where you can decouple a component from the query tree, which is very handy for places where you want to dynamically adjust things in the UI at runtime.

2/ is a known bug in the Inspect 😢 1/ you could go back in history and compare the content of the DB. I guess there are multiple changes underneath.

On 1: Fulcro renders on transactions, but Inspect watches all swaps…so every swap you do updates inspect

2 is a bug I caused when I switched how inspect gets data. It used to get a delta or full snap of state at every swap, which caused dev apps to be pretty slow. I changed it so that the app tracks history, and just sends inspect a tx number. Inspect can then pull state on demand, but my change didn’t get made to every panel, so some of them don’t know to do it, or don’t do it right.

The places I haven’t fixed are the places that I never really use it. It’s been that way for a couple years now with little complaint…I should probably just pull those out so it doesn’t cause confusion