Data Strategy Configuration

.changeset/data-strategy.md

@@ -0,0 +1,8 @@
+---
+"@remix-run/router": minor
+---
+
+Add a new `unstable_dataStrategy` configuration option
+
+- This option allows Data Router applications to take control over the approach for executing route loaders and actions
+- The default implementation is today's behavior, to fetch all loaders in parallel, but this option allows users to implement more advanced data flows including Remix single-fetch, middleware/context APIs, automatic loader caching, and more

.changeset/skip-action-revalidation.md

@@ -0,0 +1,11 @@
+---
+"@remix-run/router": minor
+---
+
+Add a new `future.unstable_skipActionRevalidation` future flag
+
+- Currently, active loaders revalidate after any action, regardless of the result
+- With this flag enabled, actions that return/throw a 4xx/5xx response status will no longer automatically revalidate
+- This should reduce load on your server since it's rare that a 4xx/5xx should actually mutate any data
+- If you need to revalidate after a 4xx/5xx result with this flag enabled, you can still do that via returning `true` from `shouldRevalidate`
+- `shouldRevalidate` now also receives a new `unstable_actionStatus` argument alongside `actionResult` so you can make decision based on the status of the `action` response without having to encode it into the action data

.changeset/static-query-flags.md

@@ -0,0 +1,8 @@
+---
+"@remix-run/router": minor
+---
+
+Added 2 new options to the `staticHandler.query` method for use in Remix's Single Fetch implementation:
+
+- `loadRouteIds`: An optional array of route IDs to load if you wish to load a subset of the matched routes (useful for fine-grained revalidation)
+- `skipLoaderErrorBubbling`: Disable error bubbling on loader executions for single-fetch scenarios where the client-side router will handle the bubbling

.gitignore

@@ -1,3 +1,4 @@
+.DS_Store
 npm-debug.log
 
 /docs/api/