By the end of the lesson, you can decide which state belongs in the URL, which stays in memory, and which on the server, and you can justify why client-side state cannot be treated as the official truth.
Why does state need to be sorted out?
A web application does not only display pages: it also manages the user's path and the momentary state of the interface. If we do not separate these, strange errors come: the Back button leads somewhere unexpected, a refresh makes the search disappear, a shared link shows something else to the recipient. State can live in three kinds of places, and each has different properties.
The student searches, selects, steps back
In the course list the student searches for the word "web", selects a course, then would return to the filtered list with the Back button. If the program only swaps the visible elements but ignores the URL and the history, the Back button can lead somewhere unexpected. If the search is lost on refresh, the student's work is interrupted. These are not graphical errors but navigation and state-management decisions.
flowchart LR
L[Filtered list] --> K[Course details]
K -->|Back| L
L -->|shareable URL| M[Another browser]
Three places for state
Place
What belongs here?
Property
URL
The identifier of the selected course, the search term, the page number
Shareable, bookmarkable, survives a refresh
Memory (the running client program)
The open help panel, the selected tab, a load in progress
Fast, but lost on refresh
Server
The actual number of places, a submitted enrolment
Official, shared by several clients
The URL is the shareable and reopenable part of the state. The identifier of a course can naturally appear in the path (/kurzusok/webprog), a search term or filter in the query (?q=web). This way the student can copy the address, refresh, and return to the same view later. Not every interface detail belongs in the URL: the state of a help panel that happens to be open and is unimportant can remain local program state.
Local and server-side state
The momentary state of the client is, for example, the value of the search field or a load in progress. The server-side state is the actual number of places of the course or a submitted enrolment. The client may display a copy or an estimate of the server's data, but must not regard it as the official truth: the "9 free places" display is a copy of the moment of the fetch, and by the time the student clicks it can be zero. At enrolment the server must decide again according to its own rules (5.5, 2.4: 409).
flowchart TD
F[Momentary state of the interface] --> U[Shareable part in the URL]
F --> M[Part managed in memory]
S[State of the server] -->|API response| F
F -->|operation request| S
If the state must not be lost, the browser can store data (3.6, local storage), but this does not mean that all interface state has to be written into IndexedDB. The place of storage is dictated by freshness, shareability, and the consequence of loss.
Interaction and accessibility
A client-side view change should not take place only visually. The user needs to understand which view they reached, what is loading, and what happened on error. The meaning of native links and buttons matters here too (3.2). When JavaScript updates the content, keyboard focus and traceability are also tasks; chapter 9 details their practice.
Worked example: the search of Kurzuspont
State
Where does it go?
Reason
The search term (web)
URL: /kurzusok?q=web
Shareable, Back and refresh work.
The selected course
URL: /kurzusok/webprog
Deep link, bookmark.
The "Details" panel is open
Memory
Unimportant, can be lost on refresh.
The state of the "Enrol" button (while sending)
Memory
Short-lived.
The number of places
Server (the client shows a copy)
Official data, shared by several clients.
The submitted enrolment
Server
The official record.
If the student sends the link to a friend, the recipient sees the same filtered list (from the URL), but not their own enrolments (from the server, with login, chapter 7).
Common misconceptions
Statement
Clarification
"The visible view is enough, the URL is secondary."
Because of sharing, refreshing, and history, the URL is part of the state.
"Client-side state is the same as the server's official data."
The client manages a copy or interface state.
"The History API paints the page automatically."
The application must build the view belonging to the URL.
"All state must be saved into IndexedDB."
The needs for preserving and sharing state differ.
In brief
State can live in three places: in the URL (shareable), in memory (fast, but erased), on the server (official).
The search term and the selected item belong in the URL; an unimportant interface detail in memory.
The client shows a copy of the server's data; the decision is made by the server.
The History API helps handle the URL and the history, but the application must build the view.
Review questions
What should go into the URL in the course search, and what should not?
Why is the "9 free places" displayed in the browser not official data?
What happens if an SPA does not handle the popstate event?
Which state is lost on refresh, and which remains?
Navigation, interactivity, and client-side state
Objectives
By the end of the lesson, you can decide which state belongs in the URL, which stays in memory, and which on the server, and you can justify why client-side state cannot be treated as the official truth.
Why does state need to be sorted out?
A web application does not only display pages: it also manages the user's path and the momentary state of the interface. If we do not separate these, strange errors come: the Back button leads somewhere unexpected, a refresh makes the search disappear, a shared link shows something else to the recipient. State can live in three kinds of places, and each has different properties.
The student searches, selects, steps back
In the course list the student searches for the word "web", selects a course, then would return to the filtered list with the Back button. If the program only swaps the visible elements but ignores the URL and the history, the Back button can lead somewhere unexpected. If the search is lost on refresh, the student's work is interrupted. These are not graphical errors but navigation and state-management decisions.
flowchart LR L[Filtered list] --> K[Course details] K -->|Back| L L -->|shareable URL| M[Another browser]Three places for state
The URL is the shareable and reopenable part of the state. The identifier of a course can naturally appear in the path (
/kurzusok/webprog), a search term or filter in the query (?q=web). This way the student can copy the address, refresh, and return to the same view later. Not every interface detail belongs in the URL: the state of a help panel that happens to be open and is unimportant can remain local program state.Local and server-side state
The momentary state of the client is, for example, the value of the search field or a load in progress. The server-side state is the actual number of places of the course or a submitted enrolment. The client may display a copy or an estimate of the server's data, but must not regard it as the official truth: the "9 free places" display is a copy of the moment of the fetch, and by the time the student clicks it can be zero. At enrolment the server must decide again according to its own rules (5.5, 2.4:
409).flowchart TD F[Momentary state of the interface] --> U[Shareable part in the URL] F --> M[Part managed in memory] S[State of the server] -->|API response| F F -->|operation request| SIf the state must not be lost, the browser can store data (3.6, local storage), but this does not mean that all interface state has to be written into IndexedDB. The place of storage is dictated by freshness, shareability, and the consequence of loss.
Interaction and accessibility
A client-side view change should not take place only visually. The user needs to understand which view they reached, what is loading, and what happened on error. The meaning of native links and buttons matters here too (3.2). When JavaScript updates the content, keyboard focus and traceability are also tasks; chapter 9 details their practice.
Worked example: the search of Kurzuspont
web)/kurzusok?q=web/kurzusok/webprogIf the student sends the link to a friend, the recipient sees the same filtered list (from the URL), but not their own enrolments (from the server, with login, chapter 7).
Common misconceptions
In brief
Review questions
popstateevent?Learning resources