Problem being solved by UI State Fragments

[atotic]

I do not understand what problems are UI state fragments trying to solve? Is this a standardized way of storing state inside hash?

Handling state in SPAs is a complex topic. Page state is composed of different data types:

ephemeral: form values, scrolling positions. ephemeral data should not be exposed in the URL. It disappears after force reload. Ephemeral data is not shared when URL is forwarded.

enduring: enduring data is exposed in the URL. In SPA, this is usually the "page" you are on. When sharing the URL, recipient will see the same page.

What is confusing me is that I consider UI state to be ephemeral, not expoesed in the URL.

This proposal explicitly stores UI state in the URL.

[bahrus]

@atotic, good question...

In my experience, the requirement to be able to send, via email, for example, a snapshot of what the user is seeing, so their colleagues can see for themselves the same exact screen (maybe not scroll position) comes up quite a bit, and is quite difficult to implement. Why should the person sending the link have to type out "now, within the page I sent, click on this tab, select these filters, then scroll down about two-thirds way" etc? Is this ephemeral / enduring distinction you are making really serving the user?

Maybe some things shouldn't persist via the link that gets sent. All this UI state fragment does is empower application developers to choose for themselves what makes sense.

Another frequent requirement -- sending out automated emails with a new report (or something), that requires navigation steps well beyond what can reasonably be described via paths / query strings.

Of less importance -- imagine how fast development could be if, when you refresh the browser with new code, you can continue debugging right where you left off, including selections made within the page?

I would suggest that developers have come to distinguish between "ephemeral" values vs enduring simply because they are taking cues from the artificial limitations browsers currently impose on us, rather than what actually best serves the user.

Imagine if the http protocol only supported sending the domain name, context path, and query strings. Now consider what adding the request body opens up.

In my mind, that's equivalent to what this proposal is doing.

Consider the scenario where you are creating a complex web page, that is being used within a native iOS application, for example. Wouldn't it be nice if the consumer of that web page could pass in complex configurations?

[tbondwilkinson]

I think it would be difficult to mandate, from a browser perspective, what websites should consider "ephemeral" or "enduring." It is often a product decision what you want to be sharable and restorable on navigations.

There are many examples of pages (Google search being one) that use the hash parameter to represent UI state, so we know it's at least in practice today. If people are already doing it, it's better to have a clearer API than exists today with the fragment.

[noamr]

ui-state also adds questions regarding privacy/persistence, added a separate issue: https://github.com/slightlyoff/history_api/issues/27