1. Location
   1. pathname
   2. state
   3. search/query
   4. hash
2. Path
   1. Dynamic Segment
   2. Wild Card
   3. Regex
3. Matching
   1. URI
   2. Parameters
   3. State
   4. Query
4. History
   1. Listener
   2. State
   3. History Stack (push/replace/index)
5. Routes
   1. Path
   2. Data
6. Links
   1. href
   2. state
   3. active status
7. File System API

When a user visits a webpage, the location is the the first (and probably the only) data the app has to generate a UI. The location is matched against a set of routes, a route is selected, (maybe) data is loaded, and finally the UI is rendered. This is the same for the client and the server.

After the initial render on the client, a history listener is set up. When the history's location changes--either through the user clicking links or the programmer redirecting with code--the new location is matched against the routes, data is fetched, and the page is displayed.

Some implementations will save the data loading of a route for after the new route's UI is rendered (and display some spinners). This allows the data loading code to be coupled to the UI that displays it rather than being attached to the route--which is farther away from the UI code.