For over a decade, most of us built web UIs operating under the assumption that servers would render mostly-static HTML, and we’d boil the ocean and free all client-side memory with every page load. This was a simple world, where the server-side was aware of the user’s intent and context.

Enter the Single Page Application (SPA) - there are all sorts of usability and performance, and scalability benefits that come along with building a web app this way, but there are also some serious challenges. There are some implicit assumptions that our users make about how apps should work, and we must work a bit harder in order to keep them intact. Take the “Back” and “Refresh” buttons, for example: in order for this to work as our users expect, we must keep certain elements of state serialized in the URL in order to avoid “breaking” this as we simulate a multi-page experience in a SPA.

Add in the concept of “server-side rendering”, where our asset serving layer sometimes needs browser details (i.e. viewport dimensions) in order to render the correct content, and state decisions become even more consequential and complex.

In this talk, I’ll outline four types of state

• Navigation state
• Persisted state
• UI state
• “Will be persisted” state

and provide examples for each. Along the way, we’ll start to assemble a framework of questions that you can ask yourself when encountering new pieces of state, to lead you down the right path(s).