Clarifying workflow event behaviour
Hey everyone ! Documenting best practices for workflow 'callback ' events . I have some edge case questions about this pattern : 1 . Provider exposes workflow via context (e .g . , updateUser ) 2 . When triggered , the workflow calls an API and defines a 'callback ' event 3 . Child components subscribe , call the workflow , and listen for 'callback ' 4 . On API completion , onSuccess triggers the callback event 5 . Child reacts (close modal , show toast , navigate , etc . ) Questions : 1 . Event Deduplication If a user double -clicks "Save " and triggers the workflow twice rapidly : - Do both executions fire separate callbacks ? - Is the API debounce option (in Advanced settings ) the intended solution ? 2 . Callback Event Scope /Lifetime If a callback fires but no component is subscribed (e .g . , component unmounted before API completed ) : - Does the event get lost (fire -and -forget ) ? - Does it queue until a subscriber appears ? - Is there any error or warning ? 3 . Multiple Subscribers If two component instances both call the same provider workflow and subscribe to callbacks : - Does each only receive callbacks for executions it triggered ? - Or do all subscribers receive all callbacks ? - Example : Two modals editing different users simultaneously 4 . Unsubscribe Behaviour When a subscribed component unmounts : - Does it automatically unsubscribe from the callback events ? Understanding these helps establish best practices for : - Preventing duplicate API calls /race conditions - Handling loading states correctly - Building robust multi -instance components Interested to hear your thoughts . Thanks ! 🙏 Clarifying workflow event behaviour Workflow callbacks are still behind a feature -flag , so I cannot answer some of the questions without testing the current state , but I can answer how I would expect it to work . Some of the answer to edge -cases may also change before the release . Secondly , while workflow callbacks are pretty useful , I think the best practice is often to avoid them and rely on data -flow from higher order components rather than callback events . 1 . Even if you call immediately after each other both the callbacks are called independently . 2 . The event will still fire , but there will be some bad side -effects . Any variable changes etc . will not actually do anything . This is an anti -pattern as I see it and if there 's not already , you may get a warning in the console informing you the component is no longer mounted . 3 . Only the one calling will get informed . If you want both to be alerted you either (by far best option in almost all cases ) use formulas to store the data and reactively update your UI as you normally would in your forms . The other option is to set up a complex broadcast system and listen to it in your callback events to call the callback multiple times each time it updates . I cannot imagine how this would look , but as always anything is possible with Nordcraft . This is basically building a data -store and broadcaster system , so not trivial (and almost certainly not needed ) . 4 . This question seems similar to question #2 . The callback events are not automatically unsubscribed on unmount if they have been triggered and running . Workflows and callbacks use a standard reference cleanup system . If the other workflow reaches to completion without calling the callback , then there is no hanging references and the callback can safely be cleaned up automatically . You generally won 't have to think about cleanup , but a workflow callback may be called on an unmounted component which you should always try to avoid logically . I have had very little use for workflow callbacks myself yet , but I 'll make sure to note down my experience in the documentation or a blogpost when I do . Hey @Jacob Kofoed Thanks for the detailed response ! I 'd love to understand the recommended reactive data -flow approach better . Scenario : User clicks "Save " in a modal → Calls provider workflow → Provider calls API → On success , the modal needs to : - Close itself - Show a success toast - Navigate to the updated user 's detail page With workflow callbacks : Provider : API onSuccess → Trigger "onSuccess " event Child : Subscribes → Receives event → Triggers workflow → Close /toast /navigate With reactive data -flow : I can use formulas to detect when the mutation succeeds (e .g . , watch Provider .lastMutationSuccess ) , but formulas can 't trigger workflows (or can they ? ) How do I trigger the workflow (to close modal , show toast , navigate ) using reactive data -flow ? Options I can think of : 1 . Use onAttributeChange to watch for formula changes and trigger a workflow (watcher pattern ) 2 . Handle everything in the child component 's workflow (but how to wait for async API completion ? ) 3 . Something else I 'm missing ? Does this make sense ? 👀1
.jpeg/public)