"Page-based" routing vs "Overlay" or "Layer" routing.

Not exactly a Pros/Cons listing, but details between each for consideration. (Please suggest more for either!)

Page based Routing:

• Routes established at a high level in the component tree
• Path-based routes seldom rely on query strings
• Shallow application state that's primarily applicable to the specific content you're viewing.
• Equally shallow component trees - components for module sub-pages are not buried within a single workflow.
• Immediate access of linked content (link from external module or clicking a FOLIO link in an email)
• Need (possibly extra) information to render links to related pages.
• Query params are emptied at each new route (unless specified in the href on the anchor that got you there)

Example of Page-based routing: this page is reached via a click-through from a Provider's detail listing - it goes directly to the linked entity without having to spin up state and search params. At the time of this writing, this view represents the need for a link to get back to where it came from (present if clicked-through from the app.)
http://folio-snapshot-stable.aws.indexdata.com/eholdings/packages/140-2118787

The url for the previous step in its workflow where the search params do live:
http://folio-snapshot-stable.aws.indexdata.com/eholdings/providers/140?searchType=providers&q=t&searchfield=title&offset=2

Layer routing/workflow

• Looks like a page, as the Layer covers the entire work area and contains a new Paneset.
• Employs combinations of state and url/query-string to expose parts of the UI.
• Requires the prerequisite state to be populated so that specific content can be viewed.
• Deep component tree, as deeper workflow components/views are deep branches of a larger tree.
• Can be perceivably slow. The user waits for the correct application state to be reached so that they can see the information they require.
• Is uncomfortable - potentially disorienting for users requiring Assistive Technology (screen readers.) Where does focus go while the state loads up? How would the application know how to differentiate from the base path?
• links out are state updates/simple js callbacks - but has been known to require a url change eventually.
• manual query string cleanup may be necessary if other workflows make use of the same query parameters.

Example of Layer-based routing:
Similar workflow to the route based example, a search, detail, and then a click-through within a listing in the Users app to open the open loans listing. All query params from search step are present in the URL. The search paneset is presented for a moment before the Loans layer renders.
http://folio-snapshot-stable.aws.indexdata.com/users/view/c77f4e96-d148-426d-a798-8692fb228b9e?filters=active.Active&layer=open-loans&query=&sort=Name

As workflows grow deeper, the's queries get longer - this is what the url for a sub-module search for a user's fines with a non-payment status and the term "digital" in the fine type. Queries from both the intial search and the search within the accounts layer are present. (From fees/fines portion of Users module, work-in-progress as of this writing.)

/users/view/c6aa6370-6eb6-4b1a-afde-7441641ae500?f=status.Non%20Payment%20i%281%29&filters=active.Active&layer=open-accounts&q=digital&query=&sort=Name

How much forensic information should a URL really hold for us? Is it really necessary for a drilled-in view of a User's loans to have a URL that contains the search query used to find the list of users the particular User was apart of? Earlier stages of the workflow should have less URL real estate and thus, be far less susceptible to query parameter collision.

Page routes should have enough information to present applicable links to related content - like and "Edit" view sending the user back to the detail view on cancellation.
Page routes leave all url query params at the disposal of their workflow - no fear of collision of params for searches within a sub-module detail page.

Some workflow stages may not require their own URL, but most will.

Use-cases we should examine:

• Accessibility - degree severity in focus jump for layer-based routing.
• sub-modules (Notes, Tags)
• Modals - editing, adding, confirmation, etc.
• Detail views of Heirarchical data relationships. (separate views for parent, children, grandchildren?)