chore: back to top links

Signed-off-by: tunnckoCore <5038030+tunnckoCore@users.noreply.github.com>

Author: tunnckoCore

README.md

@@ -154,6 +154,7 @@ import * ZagoraTypes from 'zagora/types';
 import * zagoraUtils from 'zagora/utils';
 ```
 
+[Back to top](#zagora)
 
 ## Why zagora?
 
@@ -164,6 +165,8 @@ Both `tRPC` and `oRPC` are promoted as "backend", or specifically for when you'r
 
 They are built around the network, Zagora is built around functions with excellent egonomics, developer experience, and no assumptions. **It produces just functions, i cannot stress that enough.**
 
+[Back to top](#zagora)
+
 ### Why Zagora over oRPC/tRPC/neverthrow/effect.ts?
 
 - Zagora is focused on producing "just functions", not networks, routers, or groups.
@@ -193,12 +196,16 @@ They are built around the network, Zagora is built around functions with excelle
 
 Funny enough, you can use Zagora to build fully type-safe CLIs with auto-generated detailed help, based on the provided schemas. I have another library for that, which i will overhaul soon - [zodest](https://npmjs.com/package/zodest).
 
+[Back to top](#zagora)
+
 ### Why Zagora over plain TypeScript functions?
 
 - Plain TypeScript offers compile-time types but no runtime validation — a mismatch between runtime and
   compile-time can blow up.
 - Zagora combines runtime validation/transforms (StandardSchema) with full compile-time inference, and returns a safe, uniform result tuple inspired by true functional programming
 
+[Back to top](#zagora)
+
 ### Why Zagora over standalone Zod/Valibot usage?
 
 - zagora gives a small ergonomic layer
@@ -209,6 +216,8 @@ Funny enough, you can use Zagora to build fully type-safe CLIs with auto-generat
 - single place to validate inputs/outputs/errors
 - unified non-throwing result shape
 
+[Back to top](#zagora)
+
 ## Features
 
 ### Type-Safe Input/Output Validation
@@ -229,25 +238,27 @@ const procedure = zagora()
 // NOTE: you don't need to pass `age` because it has a default value set in schema.
 const result = procedure({ name: 'John' });
 if (result.ok) {
-    console.log(result.data);
-    // ^ { id: string, age: number, verified: boolean }
+  console.log(result.data);
+  // ^ { id: string, age: number, verified: boolean }
 }
 
 // @ts-expect-error -- this will be reported at compile-time, AND error at runtime.
 const res2 = procedure('foobar');
 if (!res2.ok) {
-    console.error(res2.error);
-    // ^ { kind: 'VALIDATION_ERROR', message: string, issues: Schema.Issue[] }
+  console.error(res2.error);
+  // ^ { kind: 'VALIDATION_ERROR', message: string, issues: Schema.Issue[] }
 }
 
 // note: this will error at runtime - age is no valid schema defined number
 const resul3 = procedure({ name: 'Barry', age: -5 });
 if (!resul3.ok) {
-    console.error(resul3.error);
-    // ^ { kind: 'VALIDATION_ERROR', message: string, issues: Schema.Issue[] }
+  console.error(resul3.error);
+  // ^ { kind: 'VALIDATION_ERROR', message: string, issues: Schema.Issue[] }
 }
 ```
 
+[Back to top](#zagora)
+
 ### Typed Errors
 
 Define custom error types with schemas for better error handling.
@@ -285,6 +296,9 @@ if (res.ok) {
 }
 ```
 
+[Back to top](#zagora)
+
+### Error Type Guards
 Isn't it amazing? You will never see `Error` or `try/catch` blocks again, and everything is typed top to bottom, well-known and intuitive.
 
 But wait, there's more: **Type Guards**!
@@ -419,6 +433,8 @@ hello('invalid-keys');
 
 **Important:** if you want the error validation to actually throw on unknown keys passed to the error helper, then you need to make the error object schema more strict - just like `z.object(...).strict()`.
 
+[Back to top](#zagora)
+
 ### Context Management
 
 In some advanced scenarios, you may need to pass runtime context to handlers, like `req`, `db`, `user`, sessions, and other dependencies. It's fully typed dependency injection mechanism.
@@ -443,6 +459,7 @@ procedure('charlie');
 // => 'foo-bar has foo -> qux, id = charlie'
 ```
 
+[Back to top](#zagora)
 
 ### Object Inputs
 
@@ -453,6 +470,8 @@ zagora()
   .callable()
 ```
 
+[Back to top](#zagora)
+
 ### Tuple Inputs (Multiple Arguments)
 
 Tuple schemas is used for defining multiple arguments in a handler. It's one of the ABSOLUTE KEY features of Zagora, and it is one of the most complex stuff to achieve - but the end results is astonishing. It just works - you define schema and you get fully typed and validated arguments, INCLUDING per-argument reporting/diagnostics, INCLUDING filling defaults if `.default()` is used and respecting `.optional()`.
@@ -494,6 +513,8 @@ fnTwo('Barry', 25) // => Barry is 25, from unknown
 fnTwo('Barry', 33, 'USA') // => Barry is 33, from USA
 ```
 
+[Back to top](#zagora)
+
 ### Default Values
 
 Optionals and default values are supported at any level with any schema, whether it's through the Tuple Args, or if it's primitive schema for `string`, `array`, or `object`.
@@ -512,6 +533,8 @@ fn({ name: 'John' }) // age defaults to 18
 // => 'John is 18, from unknown'
 ```
 
+[Back to top](#zagora)
+
 ### Async Support
 
 Zagora is fully async-aware at every level of the system:
@@ -573,6 +596,8 @@ const procAsyncOutput = zagora()
 const result2 = await procAsyncOutput('hello'); // ZagoraResult
 ```
 
+[Back to top](#zagora)
+
 ### Caching/Memoization
 
 Built-in caching with custom cache adapter. Cache key includes the input, the input/output/error schemas, and handler function body. That can be used to implement custom caching strategies, and memoization.
@@ -622,6 +647,8 @@ const res = await proc(22);
 
 You can also provide the cache through `.callable({ cache })`. That is useful, if you want to provide it at "execution place", not at "definition place". For example, you'd have a set of procedures written at one place, then throgh "router" or some object that combiens them you want to call them at a `Request/Response` server handler.
 
+[Back to top](#zagora)
+
 ### Environment Variables
 
 You can provide the runtime env vars (either `process.env` or `import.meta.env`) through the second argument of `.env(schema, envs)` or at later stage through the `.callable({ env })` call. Either way, they will be validated. The parsed variables will be accessible through the handler's `options` object.
@@ -645,6 +672,8 @@ Keep in mind that if you have `autoCallable: true` enabled in the instance, then
 
 Also important to note that when `disableOptions` you will loose access to the `env` vars, as well `context` and `errors` which is normal behavior.
 
+[Back to top](#zagora)
+
 ### Handler Options Object
 
 Handlers receive an `options` (or "config") object as the first parameter containing:
@@ -687,6 +716,8 @@ zagora({ disableOptions: true })
   .handler((userId) => userId); // No options
 ```
 
+[Back to top](#zagora)
+
 ### Auto-Callable Mode
 
 Skip the need for `.callable()` call and get the procedure function directly:
@@ -707,6 +738,8 @@ hello('bob'); // ZagoraResult => 'Hello, BOB'
 hello('alice'); // ZagoraResult => 'Hello, ALICE'
 ```
 
+[Back to top](#zagora)
+
 ### Never-Throwing Guarantees
 
 Zagora ensures functions never throw - all errors are wrapped in the `Result` object:
@@ -727,6 +760,8 @@ const result = procedure();
 // result.error.cause.message === 'Oops'
 ```
 
+[Back to top](#zagora)
+
 ### Type Safety Guarantees
 
 Full TypeScript support with type inference:
@@ -739,6 +774,8 @@ And because the type system of Zagora is pretty complex, we also have tests not
 
 If you are interested, you can inspect the [test/types-testing.test.ts](./test/types-testing.test.ts) file.
 
+[Back to top](#zagora)
+
 ## API Reference
 
 ### `zagora(config?)`
@@ -763,6 +800,8 @@ Creates a new Zagora instance.
   + if `cache` passed, it will override the previously passed through `.cache` method (if so)
   + if `env` passed, it will be deep-merged with the provided through the `.env` method (if so)
 
+[Back to top](#zagora)
+
 ## Error Types
 
 - `VALIDATION_ERROR` kind - Schema validation failures