Goal: I have a multipage app and I'd like to preserve the state of pages for the user so that if they click to another page and come back, the first page state is not completely reset. How can I do this?
Steps: I think an option would be to put as much as possible inside global variables or localStorage, but that's hard to set up and maintain for many components. Another option would be to move everything to a single page app and simulate a multipage app, but that doesn't sound great either.
Details: In particular I have a table with data loaded in and a custom component that I'd also like to preserve the state for.
I believe that the only way to have data proliferate across page changes is via Global variables as outlined in our docs here.
But I understand that this can be vary tedious for apps with lots of stateful components and state data that needs to proliferate.
One option would be to have an object with a number of keys and values for each piece of data for each specific component. But I am double checking with our team now to see if there are any other options or work arounds.
Could be a good potential feature request to have a 'save state' button, although this would be at risk of being interrupted by networking/connectivity/browser issues which could lead to unexpected bugs.
The best way to save data to make sure it is being fetched is to have it stored in a database, then fetched when needed and updated as users interact further with the app.
There are some limitations on more complex stateful data, as I was working with a user who wanted an array to be preserved and this was not a data type that is supported with URL params.
The workaround for those cases is to use a Global Variable
@Jack_T ah, what I'm really looking for is preserving all page component state across navigation, which might be a dumb expectation.
My use case - user picks some filters, double clicks a row that opens a view that is implemented as a separate page. When they click "back" or "home in the nav bar", I want their filters to still be there.
The reason my view is implemented as a separate page, is that I want to be able to share links directly to my view. I guess we could implement this within the home page, but we'd have a query parameter like viewActive=1 which opens a component in the home page that shows our desired view, which still feels a little clunky.
I started using Retool after multi-page apps had been introduced so I just naturally stared using multiple pages from the start without even thinking about it. I had one Page containing the main work area, where data from many tables is combined and presented. And I used other Pages for presenting more detailed views of individual "base level" tables which need checking or updating now and again.
Pretty soon I began to find it irritating when I was working in the main Page, several levels of selections and filters deep, and needed to check or update something on another Page. Returning to the main page I'd find it had lost the context I'd set up and returned to the start. So I'd have to click around through the select lists again just to get back to where I was.
The only solution I found was to use a Tabbed container in place of Pages. I moved everything in the most needed pages (not a simple task) into separate tabs in the one main container. Unlike Pages, the Tabs retain context and I can hop back and forth between them without losing my place in any of them.
I guess multi-page Apps were introduced for some reason, so I've been meaning to ask the question whether concentrating everything in one Page is likely to lead to problems; overload, delays or anything.
Not a "dumb" expectation at all. Thank you for the added context on the use case. Having a page open on click to display additional data is very common app architecture.
I was thinking that you could have something along the lines or a URL search parameter be filter: {{table1.filterStack}} but this might only work with a single filter and not multiple.
An idea could be to set a global variable with {{table1.filterStack}} and this can be updated when filters are added/removed and then reapplied to the table when the page loads.
@davblo Yes you are correct, having a large number of queries/components on a single table will start to cause performance issues at scale. Which is a major part of why multipage was created.
With global components/global variables being the main tool for maintaining stateful data, along with URL params and local storage. But I will be surfacing the need for an automatic state capture option to our UI team as that would be very helpful for users to have a page change resume where the page was previously left.
