I have a page that contains data that refreshes automatically when a value in the database changes. Apparantly this is the default functionality, which is normally a desirable situation. In this case, I have a popup menu that allows the use to navigate to a different page (think hamburger menue) which is contained in a reuasble element. (This is relevant because from this menu I do not have direct access to elements on the current page.) The workflow that contains the naviagation, also makes a chnage to the database, which automatically causes the data on the current page to change before the use actually sees the new page they are being navigated to. Is there any way to freeze the updates on the current page prior to the naviagtion taking place. It just creates a messy interface as is.
not sure I quite understand, but as I see it there are two ways you can do it using custom states:
- you can simply add a yes/no custom state to the container holding the content you want to keep unchanged and add a step after make-changes-to that sets the state to no. Then add a condition to the container that hides this content and show a css loader for example while the state is yes.
- or you can save the old value temporarily o the page somewhere and and also use the yes/no custom state to change the source of the text to that value while the workflow is running.
Your call. Though if the user made changes to the data they should expect it to change on screen, no? unless the change is done by the app maybe.
Hey @jeff.punzel 
If you save a value as a state on the page, then it ‘freezes’ or becomes static. You can try that, or maybe hide the values on the page as the first step of your workflow before going to the other page. Do you think one of those options might help? You can also send data to a page a lot easier by using url parameters too. I’m just not sure exactly what the pages looks like to potentially give you another option. 
Hope that helps!
Thanks for the insight, but not sure a custom state will work, as I may not be able to access it from the reusable element. Even though this is not the exact use case, let me try and paint a picture for you. Imagine a page with a header, where the header is a reusable element. The reusable header element lists the name of a user and has a dropdown (floating group) that allows me to change the user I am working with. That ability to change the user would be available on any page that includes the header (likely all of them). Now, assume I have two pages in my application; a user dashboard and a user details page. If I naviage from the user deashboard into the user details page, and then I used the header dropdown to change the user, I want the system to naviage back to the dashboard for the newly selected user. However, the experience I see is that before the user is naviaged back to the dashboard, all of the user details change on the current page as a result of there being a new active user set in the header. I’d prefer that the current page with the prior user’s details remain unchange will the system i sin the process of navigating back to the dashboard. The workflow for the user selection in the header would have two steps.. 1) make the selected user the active user in the header; and 2) navigate back to the dashboard. Even if I switch the order here, I see the same results… the data on the current page changes before the user is naviaged back to the dashboard.
Seems like you need two separate reusable element
you can access a custom state if it is on the the reusable itself. so you can add an isLoading state o the reusable, toggle it to yes before you change the active user, and on the page, hide or do whatever you want with the content while the reusable’s isLoading is yes. on the new page where you naviagte to the reusable’s state will be reset.
So how are you accessing the user data on the page below? I would suggest using a url parameter instead of ‘current user’ or however you are accessing it. Just reference the data from the url parameter instead. Then it shouldn’t change until you navigate away and then send it a new url parameter.
Does that make sense?
@jeff.punzel the above is correct approach for use case you outlined