docs: teach Solid Router nested routes, server rendering, setup, and route definitions

- Nested routes: rewritten around the store's account and collections
  sections. Explains what stays mounted and why, pathless layouts as a
  sign-in check, parameters flowing down, parallel preloads at every level,
  sharing layout data through context (Solid 2 provider syntax), and a
  common-problems section.
- Server rendering: rewritten from observed behavior (no data request on
  load, one round trip per mutation, forms work with JS off) to the
  mechanism and the switches, using the fullstack template's
  server-config.ts as the reference wiring.
- Route definitions: preload examples now start the query with void and
  read it through a memo; props.data is described as captured once rather
  than shown as an awaited value.
- Setup: opens with who should read it and turns the option list into a
  when-to-reach-for-it table.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: ryansolid

src/routes/(4)routing/(1)solid-router/(1)setup.mdx

@@ -4,7 +4,10 @@ version: "2.0"
 description: "Install Solid Router, create a route tree, and mount the router instance."
 ---
 
-Install Solid Router in a Solid 2 application:
+The `basic` and `fullstack` templates from `npm create solid` already install and mount Solid Router, so if you started from one of them, skip to [Configure the router](#configure-the-router) when you need to change an option.
+The rest of this page is for adding the router to a project that does not have it, such as one created from the `bare` shape or an existing Vite app.
+
+Install it:
 
 ```sh
 pnpm add @solidjs/router@next
@@ -74,22 +77,22 @@ render(() => <App />, document.getElementById("app")!);
 
 ## Configure the router
 
-`createRouter` accepts these application-level options:
-
-- `routes` is the immutable route tree used for matching and type inference.
-- `base` prefixes matching and generated paths.
-- `preload` loads root-layout data once per mount or server request.
-- `history` selects a history adapter.
-- `preloadLinks` controls route code and data preloading from link hover, focus, and touch.
-- `explicitLinks` limits delegated routing to anchors with a `link` attribute.
-- `singleFlight` controls the server-function data consumer and defaults to `true`.
-- `actionBase` sets the server-action URL prefix and defaults to `/_server`.
-- `scrollRestoration` controls explicit back and forward scroll restoration.
-- `transformUrl` rewrites pathnames before matching.
-
-The router uses browser history by default on the client.
-The router uses the current request URL by default on the server.
-Pass `hashHistory()` or `memoryHistory()` through `history` for other client-side environments.
+Most apps pass only `routes`.
+The other options exist for a specific situation each:
+
+| Option              | Reach for it when                                                                                                                 |
+| ------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| `base`              | The app is served under a prefix such as `/app`; matching and `paths` both include it.                                            |
+| `history`           | The app is not a normal page: an Electron shell or `file://` needs `hashHistory()`, tests need `memoryHistory()`.                 |
+| `preload`           | The root layout needs data of its own; it runs once per mount or server request and reaches the root render prop as `props.data`. |
+| `preloadLinks`      | Hover and focus preloading costs more than it saves; set `false` and use `preload="false"` per link for finer control.            |
+| `explicitLinks`     | Some anchors inside the router must stay as full page loads; only anchors with a `link` attribute are then handled by the router. |
+| `scrollRestoration` | The app manages scroll itself; set `false` to stop the router restoring the position on back and forward (on by default).         |
+| `transformUrl`      | Incoming pathnames need rewriting before matching, for example to strip a locale prefix.                                          |
+| `singleFlight`      | The router's server-function data consumer should be off; it is `true` by default.                                                |
+| `actionBase`        | Server actions are served from a prefix other than the default `/_server`.                                                        |
+
+The router uses browser history by default on the client and the current request URL on the server, so `history` is rarely set in a web app.
 
 ```tsx
 import { createRouter, hashHistory } from "@solidjs/router";

src/routes/(4)routing/(1)solid-router/(2)route-definitions.mdx

@@ -4,7 +4,8 @@ version: "2.0"
 description: "Define static, parameterized, lazy, and file-system-backed Solid Router routes."
 ---
 
-A route definition maps a path pattern to a component and route behavior.
+A route definition is a plain object: a path pattern, the component to render, and optionally a preload, children, match filters, and metadata.
+This page covers each field and the two places route definitions come from, a hand-written array or the file-system adapter.
 
 ```tsx
 import { defineRoutes } from "@solidjs/router";
@@ -16,32 +17,34 @@ export const routes = defineRoutes([
 ]);
 ```
 
-Use `defineRoutes` for an extracted route array.
-The `const` type parameter preserves path literals that TypeScript would otherwise widen.
-`createRouter({ routes })` can then infer typed paths from the array.
-An inline array passed directly to `createRouter` already receives literal inference.
+The route array is also where the types come from.
+`paths.about` exists and `paths.abuot` does not because TypeScript kept the literal `"/about"`.
+An inline array passed to `createRouter` keeps its literals on its own; an array assigned to a variable first would widen to `string`, so wrap it in `defineRoutes` to preserve them.
 
 ## Type a route at its definition
 
-`defineRoute` is an identity helper that types a route component and preload from the route's own path pattern.
+Inside a route's own `component` and `preload`, `params` is an open record by default: every key is `string | undefined`, even `:id`, which the pattern guarantees.
+Wrap the route in `defineRoute` and both are typed from the route's own `path`:
 
 ```tsx
 import { defineRoute } from "@solidjs/router";
 
 const storyRoute = defineRoute({
 	path: "/stories/:id/:tab?",
-	preload: ({ params }) => getStory(params.id),
+	preload: ({ params }) => void getStory(params.id), // params.id: string
 	component: (props) => (
-		<Story story={props.data} id={props.params.id} tab={props.params.tab} />
+		<Story id={props.params.id} tab={props.params.tab} /> // tab: string | undefined
 	),
 });
 ```
 
 Required parameters such as `:id` are typed as `string`.
 Optional parameters such as `:tab?` are typed as `string | undefined`.
-The return type of `preload` becomes the component's `props.data` type.
 Parameters inherited from a parent remain accessible as `string | undefined`.
 
+Whatever `preload` returns is typed as the component's `props.data`.
+It is captured once when the route matches, so for async data the pattern on the [Data](/routing/solid-router/data) page is to start the query in `preload` with `void` and read it through a memo in the component, where it stays reactive to `params`.
+
 For a component declared in another module, annotate it with a path witness:
 
 ```tsx
@@ -197,21 +200,25 @@ An optional named `route` export can supply:
 
 ```tsx
 // routes/blog/[id].tsx
+import { createMemo } from "solid-js";
 import { int, type RouteProps } from "@solidjs/router";
 import { defineFileRoute } from "@solidjs/router/fs";
+import { getPost } from "../../data/posts";
 
 export const route = defineFileRoute("/blog/:id", {
 	matchFilters: { id: int },
-	preload: ({ params }) => getPost(params.id),
+	preload: ({ params }) => void getPost(params.id),
 });
 
 export default function Post(props: RouteProps<typeof route>) {
-	return <h1>{props.data.title}</h1>;
+	const post = createMemo(() => getPost(props.params.id));
+	return <h1>{post().title}</h1>;
 }
 ```
 
-The string passed to `defineFileRoute` is a type witness for the file's path.
-The manifest path remains the runtime source of truth.
+Inside a route file the pattern lives in the filename, so there is no `paths` node to type against.
+The string passed to `defineFileRoute` stands in for it: it types `preload`'s params, validates `matchFilters`, and lets the config double as the component's `RouteProps` witness.
+The manifest path remains the runtime source of truth; if the file moves, update the string with it.
 When the manifest has generated literal types, route paths, filters, and search schemas continue into `Router.paths`.
 
 Code-split manifest components become Solid `lazy` components.