[btown]

> treating URL parameters as your single source of truth... a URL like /?status=active&sortField=price&sortDir=desc&page=2 tells you everything about the current view

Hard disagree that there can be a single source of truth. There are (at least) 3 levels of state for parameter control, and I don't like when libraries think they can gloss over the differences or remove this nuance from the developer:

- The "in-progress" state of the UI widgets that someone is editing (from radio buttons to characters typed in a search box)

- The "committed" state that indicates the snapshot of those parameters that is actively desired to be loaded from the server; this may be debounced, or triggered by a Search button

- The "loaded" state that indicates what was most recently loaded from the server, and which (most likely) drives the data visualized in the non-parameter-controlling parts of the UI

What if someone types in a search bar but then hits "next page" - do we forget what they typed? What happens if you've just committed changes to your parameters, but data subsequently loaded from a prior commit? Do changes fire in sequence? Should they cancel prior requests or ignore their results? What happens if someone clicks a back button while requests are inflight, or while someone's typed uncommitted values into a pre-committed search bar? How do you visualize the loaded parameters as distinct from the in-progress parameters? What if some queries take orders of magnitude longer than others, and you want to provide guidance about this?

All of those questions and more will vary between applications. One size does not fit all.

If this comment resonates with you, choose and advocate for tooling that gives you the expressivity you feel in your gut that you'll need. Especially in a world of LLMs, terse syntax and implicit state management may not be worth losing that expressivity.

[chii]

> All of those questions and more will vary between applications. One size does not fit all.

all of those come from the fundamental "requirement" set out earlier to have no in-page state, but still require the webpage to behave as tho it did.

If you remove this requirement, then it will be like how it was back in the 2000's era web pages! And the url does indeed contain the single source of truth - there are no inflight requests that are not also a full page reloads.

[tempfile]

The example they used for "in progress" state was form inputs. Don't you count those as in-page state?

[chii]

until you pressed enter, this progress is understood to be ephemeral. It has only been recently that the user has been 'conditioned' to expect the form inputs to be retained when they click a link, and it's because the app is trying to retain the state of ephemeral progress.

So you cannot have both a webpage that is not an app, but maintain an app-like behaviour. Trying to do so is a cursed problem, and it might succeed with high effort, but ultimately not worth it.

[delifue]

Yes the simple solution is obviously not perfect in edge cases. It's a tradeoff between simplicity and edge-case-perfectness.

In my opinion the higher priority task is to optimize the query in backend so that it can refresh quickly. If loading is quick enough then that edge case will be less likely to happen.