Glossary
Every term the courses use, defined in one line and then in a paragraph. Written to be read out of order.
Showing 10 of 10 matching “State”
A small value the browser attaches to every request.
How a stateless protocol manages to remember you. The browser stores it and sends it automatically with each request to that site. Marking one HttpOnly prevents JavaScript from reading it, which stops an injected script stealing a session.
What a user sees when there is genuinely nothing.
The screen shown when a request succeeded and returned no items. Must look different from an error, and is the first thing every new user experiences.
See also Loading state, Skeleton
An API style where the client states what it wants.
One endpoint that accepts a description of the desired data. Fills a rich screen in one round trip with no unused fields, at the cost of much harder caching and rate limiting.
The request-and-response protocol of the web.
The rules by which a client asks and a server answers. A request is a method, a path, headers, and maybe a body; a response swaps the method for a status code. Stateless by default.
See also Status code, Stateless, Endpoint
What is shown while a request is in flight.
One of four states every piece of loaded data has. Best delayed slightly so fast responses do not flicker, then held briefly once shown so it does not flash.
See also Empty state, Skeleton
Shown, but not yet confirmed.
The honest middle ground for an optimistic update: display the change immediately, but mark it as unconfirmed. A failure then becomes a change of state rather than a contradiction.
See also Optimistic update, Loading state
The part of a URL after the question mark.
Key-value pairs carrying page state: filters, queries, sorting. Putting state here makes it shareable, survivable across refreshes, and correct with the back button. Validating it means a hand-edited URL degrades instead of crashing.
See also State, Validation
Data fetched from an API, held in the UI.
Not really your application’s state, but a cache of somebody else’s, which goes stale the moment anyone else changes it. Treating it as local state is what produces "I updated it but the list still shows the old value".
Data that can change.
The real question is never what the state is but where the authoritative copy lives: the server, the URL, component memory, or browser storage. Two copies of the same fact will eventually disagree.
See also Server state, Search params
Each request starts from nothing.
The server remembers nothing about you between requests by default. Memory has to be added deliberately, which is exactly what cookies and sessions are for.
See also HTTP, Session, Serverless