Discussion: State Management and Data Fetching

[briangregoryholmes]

This PR is WIP proposal that is to be used as a jumping off point for discussion. It shows, in a limited and unpolished capacity, a new model for handling application state, fetching data and generating URLs. This PR uses SvelteKit 2 (though does not rely on it), so run npm install.

In general, it shows a model for going from fetching the bare minimum of data required to initialize the application to a way to pass that data down to the necessary components without the use of custom writable and derived stores. It also shows a way to think of the URL as our primary form of state management by having interactive elements that invalidate/change queries be link tags or buttons that simply update routing and search params, eliminating the idea of race conditions, uncontrolled data fetching or complex dependencies. When the URL changes, the impacted load functions automatically re-run, fetching new data (often from the cache).

It also shows a way to save route specific query state not via complex custom stores, but as simply the most recent state of the URL captured before resource based navigation.

Guiding ideas:

• Follow Svelte and SvelteKit best practices and recommendations
• Set up a clear application initiation strategy and remove all cyclical or out of order dependencies
• The data fetching tree should match the application routing tree
• Move the majority of "data fetching" out of .svelte files and into +page.ts and +layout.ts files
• While not yet enabled, set up data fetching model so that SSR is a simple "switch flip"
• Move the majority of navigation based state out of JavaScript and into the URL
• Focus on generating human readable, transparent URLs as a primary form of query related state management
• Points of interaction that change queries should be <a> tags to enable data preloading and automatic query fetching
• Stream data from + files as promises and use #await blocks to handle loading and error states
• Non-URL application state should use single purpose, map-based global stores that use the class syntax, a get method and persist data via localStorage or sessionStorage
• Soft max of two Go To Definitions to understand the source of critical state or data
• Components should be as "dumb" as possible

Goals:

• Significantly reduce the amount of client side JavaScript required to initialize the application
• Reduce build times and bundle sizes
• Reduce time to first paint by >50% (once SSR is enabled)
• Near zero flashing of layout components when refreshing
• Exploit SvelteKit's data prefetching to avoid/reduce spinner visibility
• Reduce required testing surface
• Further down the line: Unify Rill Cloud and Rill Developer