I’ll give more context, as I can’t seem to convince the Retool team that rerunning queries is not always the best idea.
Imagine we create an app with a tabbed container, that has 7 tabs. On pageload, a query runs to get the data that’ll be displayed in the first tab…but not the queries that will populate the other 6 tabs. Only if/when a user clicks on one of those other 6 tabs will its query be run, and data gotten. Why? This will dramatically speed up pageload time/reduce api calls, by not making all 7 queries run on pageload.
Additionally, once that query is run one time, we will not run it again. This way the user can click to another tab, then click back to the previous tab, and we won’t have to rerun the query. It was already run, data already gotten, so the tab will load instantly. Thus we are implementing “get the data the first time the tab is clicked on, but not any times after that” This makes the app snappy, quick, breezy to use.
This is quite simple logic…unless we do what your team is suggesting (rerunning all of the queries every time url query string param changes)
Additionally, imagine we add in modals that implement similar “get data only if interacted with” logic. And some forms. And a workflow or two. And store some of this data in localstorage.
Now “just rerun all the queries” has become an unholy, unmaintainable impossibility. Even if one builds an app less complicated than I describe, “rerunning all of the queries” means additional code that is not always easily maintainable.
Simply whitelisting location.reload would allow us to solve this.
@aviator22 sorry if I misunderstood, your original post seemed to say that you wanted to re-run all your queries by reloading. We are def aware of how running queries on page load can slow down apps, and recommend against it here.
@alex-w mentioned that you were able to chat about this offline, too. I’m adding it into the backlog to work on whitelisting that function