So I’m in the process of designing a dashboard for an analysis environment. I wanted to try out the Dash DAQ Indicator to indicate whether there’s still an analysis waiting in a queue. A similar pattern arises in other places (it’s not only potentially long-running callbacks, before we end-up replicating those threads), but it’s an easy one to grasp at the least.
I ended up with adding some buttons which add items to a queue that’s managed in a dcc.Store.
When there are items in the queue, the indicator should be True (on) and analysis callbacks should fire to process queue items.
This would cause result divs to update, after which their entries should be removed from the queue.
However, removing the item from the queue involves a circular dependency, as adding the item started the process in the first place.
Pattern:
Button -> Store -> Result -> Store
-> Indicator
Where naturally the Store ends up in a loop (until the queue is empty).
I guess I’m just not used to the design pattern where things can only move forward (and only the user can start a new cycle).
However, taking something from a queue and updating afterwards seems like it should be possible.
The only half-feasable solution I was able to come up with is polling at intervals somewhere in the loop and providing a State() instead of Input() of the other argument.
I believe the pattern would simplify somewhat if there were Events built in, but there must be a good reason why support for Events has been dropped.
Any ideas or patterns I should look into to replace/avoid/circumvent this?