Architecture question: how to handle large state needed in many places

[andreasWallner]

I have a bit of a general question regarding how to handle state in the application that is needed in multiple places.
To give a bit of context, I work on surfer, a digital waveform viewer using (obviously) egui (there is an online version of it, in case anyone is interested - just click on "click here to open an example...").

The problem that I'm encountering is the following:
We have a bunch of state that is needed across the application, but it inherently display-related. In my concrete case this is "which waveforms in the main dialog are selected". From my understanding of egui that information should (?) be stored in the state of the widget itself - but due to us needing it in many places (query via network, information for completing our "console", running console commands, also interacting with data caches, etc.) we placed it in our state, with some abstraction to handle moving, expanding/collapsing our tree/etc.
All of the interaction with the UI is done via a message queue, also selection changes.

This now creates a problem for me, because as a reaction to a click I'd need to first update the selection accordingly, then display the context menu, and our context menu should be responsive to what is currently selected.
...But due to the selection happening only in the next frame (it just got put into the message queue) this becomes quite a bit annoying...

As far as I understand, we could do a few things:

• pass the state to the renderer mutably (see Managing state in a recursively rendered UI #5525 (reply in thread)), which I'd like to avoid to not run into issues of order of operations
• pass the state, modify it and return a new one - same as above (sry, can't remember the discussion I read that in)
• duplicate the selection logic, and calculate it twice - once to know which dialog options to show, the second time to update the state when the message is received
• move the selection update into the widget, and send the updated data-structure via message - seems bad, especially considering that we can get a command from the network in the meantime that might make our state inconsistent
• delay showing the context menu by one frame - seems to get just as messy as the other solutions
• put selection, order, etc. information into the Widget, and provide an API to retrieve & update it from the rest of the application (as mentioned in A Map widget for egui: review needed #5662 (comment)) - certainly doable, but a bunch of work (make state store/restore/undo/etc. a bunch harder)
• ?

I somehow have the feeling that the last option might the the "proper" one - but I'm hesitant to go down that route and I would involve major changes, and involve a bunch of other problems, like inconsistent frames when I handle the click on a label after a bunch are already rendered... (also harder testing, etc.)

And thoughts/hints/ideas on this matter?