docs: more reorganizing and updates to docs

Author: imp-dance

docs/docs/Features/defer-queries.md renamed to docs/docs/Features/defer-queries.mdx

@@ -30,6 +30,11 @@ const loader = createLoader({
 });
 ```
 
+<img
+  src={require("./deferred.png").default}
+  alt="Deferred queries timeline"
+/>
+
 ## Configure
 
 > **New in version 1.0.3**

docs/docs/Features/deferred.png

@@ -0,0 +1,72 @@
+---
+sidebar_position: 1
+---
+
+# Extend
+
+You can **extend** existing `Loader`s. This lets you inherit and overwrite properties from an existing `Loader`.
+
+## Example
+
+```tsx
+const parentLoader = createLoader({
+    onLoading: () => <div>Loading...</div>
+});
+
+const childLoader = parentLoader.extend({
+    useQueries: () => ({...}),
+    onError: () => <div>Error</div>,
+}).extend({
+    transform: () => ({...}),
+}).extend({
+    onLoading: () => <div>Overwritten loading...</div>,
+});
+```
+
+## Separation of concerns
+
+Its up to you how much you want to separate logic here. Some examples would be...
+
+- Co-locating loaders in a shared folder
+- Co-locating loaders in same file as component
+- Co-locating loaders in same directory but in a separate file from the component
+
+I personally prefer to keep the loaders close to the component, either in a file besides it or directly in the file itself, and then keep a base loader somewhere else to extend from.
+
+## Creating a loader hierarchy
+
+You can extend from any loader, including loaders that have already been extended. This allows you to create a hierarchy of loaders that can be used to share logic between components.
+
+<img
+  src={require("../Quick Guide/extend-loader.png").default}
+  alt="Loader hierarchy illustration"
+/>
+
+## Tips
+
+:::caution `.extend` will not merge what two separate `useQueries` returns.
+For example, you cannot _just_ inherit the deferredQueries, you must either inherit or overwrite the whole `useQueries` argument.
+:::
+
+:::tip Reusable transformers
+You can extend as many times as you'd like. You can use this feature to easily inject reusable snippets, like transformers.
+
+```typescript
+type QueryRecord = Record<string, UseQueryResult<unknown>>;
+
+export const transformData = {
+  transform: (data: {
+    queries: QueryRecord;
+    deferredQueries: QueryRecord;
+    payload: unknown;
+  }) => {
+    // handle transformation in generic way
+  },
+};
+```
+
+```typescript
+const loader = createLoader({...}).extend(transformData);
+```
+
+:::

docs/docs/Features/extending.md

@@ -0,0 +1,82 @@
+# Passing arguments
+
+You can setup loaders so that they can be used with arguments. How you pass the arguments depends on how you use the loader.
+
+You set this up using the `queriesArg` argument. This is a function that takes the consumer's expected props and returns the argument that should be passed to the useQueries hook.
+
+```tsx
+const loader = createLoader({
+  queriesArg: (props: { userId: string }) => props.userId,
+  useQueries: (userId) => {
+    // userId is automatically inferred as string
+    const user = useGetUserQuery(userId);
+
+    return {
+      queries: {
+        user,
+      },
+    };
+  },
+});
+```
+
+## Data flow
+
+The transformation layer between the useQueries hook and the loader is the `queriesArg` function.
+
+It takes the component's props and returns the argument that should be passed to the useQueries hook. This is nessecary to be able to consume the loader in a type-safe way through withLoader.
+
+<img
+  src={require("../Quick Guide/queriesArg.png").default}
+  alt="queriesArg"
+  style={{ maxWidth: "100%" }}
+/>
+
+## When using `<AwaitLoader />`
+
+You should pass the expected _props_ to the `arg` prop when using `<AwaitLoader />`.
+
+```tsx
+<AwaitLoader
+    loader={loader}
+    render={(data) => (...)}
+    args={{
+        userId: "1234",
+    }}
+/>
+```
+
+## Properly typing the `queriesArg` function
+
+You can use the `ConsumerProps<T>` utility type to type the `queriesArg` function.
+
+```tsx
+import {
+  ConsumerProps,
+  createLoader,
+} from "@ryfylke-react/rtk-query-loader";
+
+type UserRouteLoaderProps = ConsumerProps<{
+  userId: string;
+}>;
+
+const loader = createLoader({
+  queriesArg: (props: UserRouteLoaderProps) => props.userId,
+  // ...
+});
+```
+
+The type utility will ensure that the type can be extended by the consumer components. This means that the following types are both valid for the definition above:
+
+```ts
+// This is valid ✅
+type Props_1 = {
+  userId: string;
+};
+
+// This is also valid ✅
+type Props_2 = {
+  userId: string;
+  someOtherProp: string;
+};
+```

docs/docs/Features/extending.mdx

@@ -6,6 +6,8 @@ sidebar_position: 2
 
 You can transform the queries to any format you'd like.
 
+## Example
+
 ```ts
 const notTransformed = createLoader({
   useQueries: () => ({

docs/docs/Features/passing-arguments.mdx

@@ -31,62 +31,3 @@ export const userRouteLoader = baseLoader.extend({
   },
 });
 ```
-
-## Data flow
-
-The transformation layer between the useQueries hook and the loader is the `queriesArg` function. It takes the component's props and returns the argument that should be passed to the useQueries hook. This is nessecary to be able to consume the loader in a type-safe way.
-
-<img
-  src={require("./queriesArg.png").default}
-  alt="queriesArg"
-  style={{ maxWidth: "100%" }}
-/>
-
-## When using `<AwaitLoader />`
-
-You should pass the expected _props_ to the `arg` prop when using `<AwaitLoader />`.
-
-```tsx
-<AwaitLoader
-    loader={loader}
-    render={(data) => (...)}
-    args={{
-        userId: "1234",
-    }}
-/>
-```
-
-## Properly typing the `queriesArg` function
-
-You can use the `ConsumerProps<T>` utility type to type the `queriesArg` function.
-
-```tsx
-import {
-  ConsumerProps,
-  createLoader,
-} from "@ryfylke-react/rtk-query-loader";
-
-type UserRouteLoaderProps = ConsumerProps<{
-  userId: string;
-}>;
-
-const loader = createLoader({
-  queriesArg: (props: UserRouteLoaderProps) => props.userId,
-  // ...
-});
-```
-
-The type utility will ensure that the type can be extended by the consumer components. This means that the following types are both valid for the definition above:
-
-```ts
-// This is valid ✅
-type Props_1 = {
-  userId: string;
-};
-
-// This is also valid ✅
-type Props_2 = {
-  userId: string;
-  someOtherProp: string;
-};
-```

docs/docs/Features/transforming.md

@@ -13,22 +13,3 @@ export const userRouteLoader = baseLoader.extend({});
 ```
 
 You can pass any argument from [`createLoader`](/Reference/create-loader) into [`Loader.extend`](/Features/extending).
-
-:::info Separation of concerns
-Its up to you how much you want to separate logic here. Some examples would be...
-
-- Co-locating loaders in a shared folder
-- Co-locating loaders in same file as component
-- Co-locating loaders in same directory but in a separate file from the component
-
-I personally prefer to keep the loaders close to the component, either in a file besides it or directly in the file itself, and then keep a base loader somewhere else to extend from.
-:::
-
-## Loader hierarchy
-
-You can extend from any loader, including loaders that have already been extended. This allows you to create a hierarchy of loaders that can be used to share logic between components.
-
-<img
-  src={require("./extend-loader.png").default}
-  alt="Loader hierarchy illustration"
-/>