Document a Philosophy for our URL routing scheme

[tgolen]

Coming from this thread in #generalists room.

Problem

The routes used in the App are added based on individual best guesses on what patterns to follow when adding new routes. This lack of cohesion leads to difficulty when we want to plan for large-scale navigation changes (such as switching to a three-pane layout where different panes use different URLs).

Solution

Try to write down what our current philosophy is on URL routing.

[tgolen]

Analysis

Here are all the routes that currently exist: https://docs.google.com/spreadsheets/d/1GC5WqzmOXhwYpQgC9DCtoAzrQ2OcULi-YsNlfFWzQQ0/edit?usp=sharing

They fall into a couple of general buckets.

• Routes based on page (eg. /settings, /teachersunite)
• Routes based on action usually followed by an object (eg. /new/task, /create/split, /send, /sign-in-with-saml)
• Routes based on object (eg. /r, /workspace, /bank-account)

Then there are quite a few extra things put into the URL path:

• domains
• report IDs
• transaction IDs
• report action IDs
• policy IDs
• step indexes

Then there are also some query parameters:

• backTo
• login
• policyID
• country
• currency

Some routes use optional params. Examples:

• r/:reportID? - can be either:
  • /r - load the last accessed report or concierge
  • /r/<reportID> - load a specific report
• bank-account/:stepToOpen?

Some routes are prepended with / while others aren't.

[tgolen]

Proposed Philosophy

[tgolen]

This is mostly done. Some ongoing chatter, but I at least got something written down