@Damian thanks a lot for all the help so far. In our team, we had a more detailed discussion on what the challenges resulting from this are and there is still a fair bit of confusion. I’ll try to formulate them, maybe someone can answer. Potentially even somebody from plotly. (@chriddyp 
)
The whole problem for me behind the refreshing is that your app might be connected to some real object which should preserve its current state when reloading/refreshing.
For the most parts, this worked by saving old states to a file and initializing all UI components from that, making sure nothing is lost. This only works on app-start though.
One thing I noticed while testing is that on Refresh the objects representing the real-life device stay in the same memory path, but refreshing resets them to their ‘default’ state, which is either the stuff from the previous save file or just some default value. I think I lack the proper understanding of the server architecture, but does Dash keep some sort of initial state of all objects to use in refreshs?
Another issue is that, when opening the app in more than one tab for example, they share the same objects, but the UI will never be the same. Is there a way to achieve this? What are the implications for deployment on a server? Does each user work on the same instance of the app? If not, can this be implemented, since technically, when working with physical devices, one will only have a single instance? And if it can be implemented, can it be done in a way that accounts for conflict other than using an interval which tries to get new values?
Is their perhaps a better way to work around these issues using e.g. gunicorn?
I guess the most appropriate formulation of the question would then be: How can one preserve the state of an app on close/refresh/reload/with-multiple-users most efficiently?
EDIT: I guess it is also related to Is classical State-less architecture suitable for Data Science products?