Are there any best practices/guidelines for triggering mutations from mutations? What I'm trying to model: 1. Show text input prompt to user. 2. User enters answer. 3. Transact to answer completed state. 4. One second later transact to hide prompt/reset state. So I want a side effect in mutation 3. Right now I'm handling it in didComponentUpdate determining when the data that transaction 3. changes is updated and then invoking a setTimeout there that triggers the follow-up transaction. I'm curious if there are other solutions.

@danvingo So this is kind of an open area still. You can technically call transact! from within an action of a mutation (though not within a swap! on the state atom). I’ve long considered this an undesirable practice, but it is sometimes just the most convenient thing to do. If you use ptransact! it is auto-delayed (setTimeout 0), so that is usually what I call (it is documented as being safe to use within transactions because of this delay).

If your use-case is because of I/O (remoting) , then ptransact! might give you what you want. The delay component is pretty much done the way you say, though: setTimeout and transact within it on the reconciler.

From your description, I’m not sure why you need another transact inside of (3)…just sounds like state updates to me….so that would be more along the lines of functional composition with mutation helpers that work on state map…as described int the book. The only real time that you need transact! inside of a running mutation is when you want to trigger (one or more) remote interactions that are in other mutations.

If it is just data loading for remotes, then you can use load-action…and if it is that your mutation needs to do something different on the remote than the mutation that was invoked you can return an AST for a single call for the remote to “morph” the mutation to a completely different remote mutation. Lots of options

@tony.kay is there a way to get the fulcro app from a component instance? (like we do for reconciler)

nope…app has to be saved in your own external atom

@wilkerlucio I guess we could have it set itself as a prop on the mount node? Don’t know where else to put it really

I think that makes sense

you’re talking about from a tooling sense? Like with your workspace cards

yeah, I don't actually need it now, but I though myself looking for it a couple times, could be useful

but in reality, most of the time reconciler is enough, but feels like a missing thing to me

the book suggests you save it in your own atom, and I think the tool registry will give it to you

the issue when there are too many apps to take account, linking back is not always strait forward, sure it's possible, but it could be easier