Loading...
+ Error: {data.error}
+ Outcome 1
+Outcome 2
+Outcome 1
+Outcome 2
+Red
+const GreenDiv = () => Green
+const BlueDiv = () => Blue
+
+const options = {
+ red: RedDiv,
+ green: GreenDiv,
+ blue: BlueDiv,
+}
+
+function App() {
+ const [selected, setSelected] = createSignal("red")
+
+ return (
+ <>
+
+ Error: {err.message}
}>
+ -
+ {
+ // add the new item to the list
+ }}
+ />
+
- + {item} - {index()} + + )} +
...
+...
+`. If you portal into an SVG, then the `isSVG` prop must be used to avoid wrapping the children in a `
+```
+
+## Props
+
+| Name | Type | Description |
+| :--------- | :-------------------------------------------------------------- | :------------------------------------------------------ |
+| `fallback` | `JSX.Element \| ((err: any, reset: () => void) => JSX.Element)` | The fallback content to render when an error is caught. |
+
+
+---
+title:
+order: 5
+---
+
+The `` component is used to render a list of items. It is similar to the `.map()` function in JavaScript.
+
+```ts
+import { For } from "solid-js"
+import type { JSX } from "solid-js"
+
+function For(props: {
+ each: readonly T[]
+ fallback?: JSX.Element
+ children: (item: T, index: () => number) => U
+}): () => U[]
+```
+
+A referentially keyed loop with efficient updating of only changed items. The callback takes the current item as the first argument:
+
+```jsx
+Loading...
}>
+ {(item) => ` and wrap in a `` instead.
+
+```jsx
+import { Portal } from "solid-js/web"
+
+function Rect() {
+ return (
+
+
+ );
+}
+
+function SVG() {
+ return ;
+}
+```
+
+
+
+---
+title: Derived signals
+order: 1
+---
+
+Derived signals are functions that rely on one or more [signals](/concepts/signals) to produce a value.
+
+These functions are not executed immediately, but instead are only called when the values they rely on are changed.
+When the underlying signal is changed, the function will be called again to produce a new value.
+
+```js
+const double = () => count() * 2;
+```
+
+In the above example, the `double` function relies on the `count` signal to produce a value.
+When the `count` signal is changed, the `double` function will be called again to produce a new value.
+
+Similarly you can create a derived signal that relies on a store value because stores use signals under the hood.
+To learn more about how stores work, [you can visit the stores section](/concepts/stores).
+
+```js
+const fullName = () => store.firstName + ' ' + store.lastName;
+```
+
+These dependent functions gain reactivity from the signal they access, ensuring that changes in the underlying data propagate throughout your application.
+It is important to note that these functions do not store a value themselves; instead, they can update any effects or components that depend on them.
+If included within a component's body, these derived signals will trigger an update when necessary.
+
+While you can create derived values in this manner, Solid created the [`createMemo`](/reference/basic-reactivity/create-memo) primitive.
+To dive deeper into how memos work, [check out the memos section](/concepts/derived-values/memos).
+
+
+---
+title: Memos
+order: 2
+---
+
+Memos are a type of reactive value that can be used to memoize derived state or expensive computations.
+They are similar to [derived signals](/concepts/derived-values/derived-signals) in that they are reactive values that automatically re-evaluate when their dependencies change.
+However, unlike derived signals, memos are optimized to execute only once for each change in their dependencies.
+
+Memos expose a _read-only_ reactive value (like a [signal](/concepts/signals)) and track changes in their dependencies (similar to an [effect](/concepts/effects)).
+This makes them useful for caching the results of expensive or frequently accessed computations.
+By doing this, memos minimize unnecessary work within an application by retaining the results of a computation until its dependencies change.
+
+## Using memos
+
+A memo is created using the `createMemo` function.
+Within this function, you can define the derived value or computations you wish to memoize.
+When called, `createMemo` will return a **getter** function that reads the current value of the memo:
+
+```jsx
+import { createMemo, createSignal } from "solid-js"
+
+const [count, setCount] = createSignal(0)
+
+const isEven = createMemo(() => count() % 2 === 0)
+
+console.log(isEven()) // true
+
+setCount(3)
+console.log(isEven()) // false
+```
+
+While memos look similar to effects, they are different in that they _return a value_.
+This value is the result of the computation or derived state that you wish to memoize.
+
+### Advantages of using memos
+
+While you can use a [derived signal](/concepts/derived-values/derived-signals) to achieve similar results, memos offer distinct advantages:
+
+- Memos are optimized to execute only once for each change in their dependencies.
+- When working with expensive computations, memos can be used to cache the results so they are not recomputed unnecessarily.
+- A memo will only recompute when its dependencies change, and will not trigger subsequent updates (as determined by [`===` or strict equality](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Strict_equality)) if its dependencies change but its value remains the same.
+- Any signal or memo accessed within a memo's function is **tracked**.
+ This means that the memo will re-evaluate automatically when these dependencies change.
+
+
+When a signal updates, it notifies all of its subscribers sequentially but the *order can vary*.
+While effects are guaranteed to run when a signal updates, the execution might **not** be instantaneous.
+This means that the order of execution of effects is *not guaranteed* and should not be relied upon.
+
+
+### Nested effects
+
+When working with effects, it is possible to nest them within each other.
+This allows each effect to independently track its own dependencies, without affecting the effect that it is nested within.
+
+```jsx
+createEffect(() => {
+ console.log("Outer effect starts");
+ createEffect(() => console.log("Inner effect"));
+ console.log("Outer effect ends");
+});
+```
+
+The order of execution is important to note.
+An inner effect will _not_ affect the outer effect.
+Signals that are accessed within an inner effect, will _not_ be registered as dependencies for the outer effect.
+When the signal located within the inner effect changes, it will trigger only the _inner effect_ to re-run, not the outer one.
+
+```jsx
+import { createSignal, createEffect } from "solid-js";
+
+const [count, setCount] = createSignal(0);
+
+createEffect(() => {
+ console.log("Outer effect starts");
+ createEffect(() => console.log(count())); // when count changes, only this effect will run
+ console.log("Outer effect ends");
+});
+```
+
+This forces each effect to be independent of each other, which helps to avoid unexpected behaviour.
+Additionally, it allows you to create effects that are only triggered when certain conditions are met.
+
+## Lifecycle functions
+
+Effects have a lifecycle that can be managed using certain functions.
+These functions allow you to control the initialization and disposal of effects to build the type of behaviour that you need.
+This can include running a side effect only once, or cleaning up a task when it is no longer needed.
+
+### `onMount`
+
+In situations where you just want to run a side effect **once**, you can use the [`onMount`](/reference/lifecycle/on-mount) function.
+This lifecycle function is similar to an effect, but it does not track any dependencies.
+Rather, once the component has been initialized, the `onMount` callback will be executed and will not run again.
+
+```jsx
+import { onMount } from "solid-js";
+
+function Component() {
+ const [data, setData] = createSignal(null);
+
+ createEffect(() => {
+ data(); // will run every time data changes
+ });
+
+ onMount(async () => {
+ // will run only once, when the component is mounted
+ const fetchedData = await fetch("https://example.com/data");
+ setData(fetchedData);
+ });
+
+ return
+In TypeScript, you must use a definitive assignment assertion.
+Since Solid takes care of assigning the variable when the component is rendered, this signals to TypeScript that the variable will be assigned, even if it can't
+confirm it.
+
+```tsx
+let myElement!: HTMLDivElement;
+```
+
+
+### Signals as refs
+
+[Signals](/concepts/signals) can also be used as refs.
+This is useful when you want to access the element directly, but the element may not exist when the component is first rendered, or may be removed from the DOM at some point.
+
+```jsx
+function App() {
+ const [show, setShow] = createSignal(false)
+ const [element, setElement] = createSignal()
+
+ return (
+
+ The syntax using `[` and `]` is called [array destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment).
+
+This lets you extract values from the array.
+In the context of `createSignal`, the first value is the getter function, and the second value is the setter function.
+
+
+
+## Accessing values
+
+The getter function returned by `createSignal` is used to access the value of the signal.
+You call this function with no arguments to get the current value of the signal:
+
+```jsx
+console.log(count()); // output: 0
+```
+
+## Updating values
+
+The setter function returned by `createSignal` is used to update the value of the signal.
+This function takes an argument that represents the new value of the signal:
+
+```jsx
+setCount(count() + 1);
+
+console.log(count()); // output: 1
+```
+
+The setter function can also take a function that passes the previous value.
+
+```jsx
+setCount((prevCount) => prevCount + 1);
+
+console.log(count()); // output: 1
+```
+
+## Reactivity
+
+Signals are reactive, which means that they automatically update when their value changes.
+When a signal is called within a [tracking scope](/concepts/intro-to-reactivity#tracking-changes), the signal adds the dependency to a list of subscribers.
+Once a signal's value changes, it notifies all of its dependencies of the change so they can re-evaluate their values and update accordingly.
+
+```jsx
+function Counter() {
+ const [count, setCount] = createSignal(0);
+ const increment = () => setCount((prev) => prev + 1);
+
+ return (
+
+A tracking scope can be created by [`createEffect`](/reference/basic-reactivity/create-effect) or [`createMemo`](/reference/basic-reactivity/create-memo), which are other Solid primitives.
+
+Both functions subscribe to the signals accessed within them, establishing a dependency relationship.
+Once this relationship is established, the function is notified whenever the signal changes.
+
+
+
+To learn more about how to use Signals in your application, visit our [state management guide](/guides/state-management).
+
+
+---
+title: Stores
+order: 6
+---
+
+Similar to [signals](/concepts/signals), stores are a state management primitive.
+However, while signals manage a single piece of state, stores create a centralized location to reduce code redundancy.
+Within Solid, these stores can spawn a collection of reactive signals, each corresponding to a particular property which can be useful when working with complex state.
+
+## Creating a store
+
+Stores can manage many data types, including: objects, arrays, strings, and numbers.
+
+Using JavaScript's [proxy](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) mechanism, reactivity extends beyond just the top-level objects or arrays.
+With stores, you can now target nested properties and elements within these structures to create a dynamic tree of reactive data.
+
+```jsx
+import { createStore } from "solid-js/store"
+
+// Initialize store
+const [store, setStore] = createStore({
+ userCount: 3,
+ users: [
+ {
+ id: 0,
+ username: "felix909",
+ location: "England",
+ loggedIn: false,
+ },
+ {
+ id: 1,
+ username: "tracy634",
+ location: "Canada",
+ loggedIn: true,
+ },
+ {
+ id: 2,
+ username: "johny123",
+ location: "India",
+ loggedIn: true,
+ },
+ ],
+})
+```
+
+## Accessing store values
+
+Store properties can be accessed directly from the state proxy through directly referencing the targeted property:
+
+```jsx
+console.log(store.userCount) // Outputs: 3
+```
+
+Accessing stores within a tracking scope follows a similar pattern to signals.
+While signals are created using the [`createSignal`](/reference/basic-reactivity/create-signal) function and require calling the signal function to access their values, store values can be directly accessed without a function call.
+This provides access to the store's value directly within a tracking scope:
+
+```jsx
+const App = () => {
+ const [mySignal, setMySignal] = createSignal("This is a signal.")
+ const [store, setStore] = createStore({
+ userCount: 3,
+ users: [
+ {
+ id: 0,
+ username: "felix909",
+ location: "England",
+ loggedIn: false,
+ },
+ {
+ id: 1,
+ username: "tracy634",
+ location: "Canada",
+ loggedIn: true,
+ },
+ {
+ id: 2,
+ username: "johny123",
+ location: "India",
+ loggedIn: true,
+ },
+ ],
+ })
+ return (
+
+Separating the read and write capabilities of a store provides a valuable debugging advantage.
+
+This separation facilitates the tracking and control of the components that are accessing or changing the values.
+
+
+ A little hidden feature of stores is that you can also create nested stores to help with setting nested properties.
+
+```jsx
+ const [store, setStore] = createStore({
+ userCount: 3,
+ users: [ ... ],
+ })
+
+ const [users, setUsers] = createStore(store.users)
+
+ setUsers((currentUsers) => [
+ ...currentUsers,
+ {
+ id: 3,
+ username: "michael584",
+ location: "Nigeria",
+ loggedIn: false,
+ },
+ ])
+
+```
+ Changes made through `setUsers` will update the `store.users` property and reading `users` from this derived store will also be in sync with the values from `store.users`.
+
+ Note that the above relies on `store.users` to be set already in the existing store.
+
+
+
+## Path syntax flexibility
+
+Modifying a store using this method is referred to as "path syntax."
+In this approach, the initial arguments are used to specify the keys that lead to the target value you want to modify, while the last argument provides the new value.
+
+String keys are used to precisely target particular values with path syntax.
+By specifying these exact key names, you can directly retrieve the targeted information.
+However, path syntax goes beyond string keys and offers more versatility when accessing targeted values.
+
+Instead of employing the use of just string keys, there is the option of using an array of keys.
+This method grants you the ability to select multiple properties within the store, facilitating access to nested structures.
+Alternatively, you can use filtering functions to access keys based on dynamic conditions or specific rules.
+
+
+ If your *store* is an array, you can specify a range of indices using an object with `from` and `to` keys.
+
+```jsx
+const [store, setStore] = createStore([]) // A store that is an array
+...
+setStore({ from: 1, to: store.length - 1 }, "loggedIn", false)
+```
+
+In addition to this, including the `by` key, can help you perform iterative updates within an array, which can be useful when you want to update elements at regular intervals.
+This key defines the step size for index increments, similar to a [`for` loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for):
+
+```jsx
+setStore({ from: 0, to: store.length, by: 2 }, "loggedIn", false)
+```
+
+
+
+### Dynamic value assignment
+
+Path syntax also provides a way to set values within an array using functions instead of static values.
+These functions receive the old value as an argument, allowing you to compute the new value based on the existing one.
+This dynamic approach is particularly useful for complex transformations.
+
+```jsx
+setStore("users", 3, "loggedIn" , (loggedIn) => !loggedIn)
+```
+
+### Filtering values
+
+In scenarios where you want to update elements in an array based on a specific condition, you can pass a function as an argument.
+This function will act as a filter, allowing you to select elements that satisfy the condition.
+It receives the old value and index as arguments, providing the flexibility to make conditional updates.
+
+```jsx
+setStore("users", (user) => user.username.startsWith("t"), "loggedIn", false)
+```
+
+In addition to [`.startsWith`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith), you can use other array methods like [`.find`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find) to filter for the values that you need.
+
+## Modifying objects
+
+When using store setters to modify objects, if a new value is an object, it will be shallow merged with the existing value.
+What this refers to is that the properties of the existing object will be combined with the properties of the "new" object you are setting, updating any overlapping properties with the values from the new object.
+
+What this means, is that you can directly make the change to the store _without_ spreading out properties of the existing user object.
+
+```jsx
+setStore("users", 0, {
+ id: 109,
+})
+
+// is equivalent to
+
+setStore("users", 0, (user) => ({
+ ...user,
+ id: 109,
+}))
+```
+
+## Store utilities
+
+### Store updates with `produce`
+
+Rather than directly modifying a store with setters, Solid has the `produce` utility.
+This utility provides a way to work with data as if it were a [mutable](https://developer.mozilla.org/en-US/docs/Glossary/Mutable) JavaScript object.
+`produce` also provides a way to make changes to multiple properties at the same time which eliminates the need for multiple setter calls.
+
+```jsx
+import { produce } from "solid-js/store"
+
+// without produce
+setStore("users", 0, "username", "newUsername")
+setStore("users", 0, "location", "newLocation")
+
+// with produce
+setStore(
+ "users",
+ 0,
+ produce((user) => {
+ user.username = "newUsername"
+ user.location = "newLocation"
+ })
+)
+```
+
+`produce` and `setStore` do have distinct functionalities.
+While both can be used to modify the state, the key distinction lies in how they handle data.
+`produce` allows you to work with a temporary draft of the state, apply the changes, then produce a new [immutable](https://developer.mozilla.org/en-US/docs/Glossary/Immutable) version of the store.
+Comparatively, `setStore` provides a more straightforward way to update the store directly, without creating a new version.
+
+It's important to note, however, `produce` is specifically designed to work with **arrays** and **objects**.
+Other collection types, such as JavaScript [Sets](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) and [Maps](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map), are not compatible with this utility.
+
+### Data integration with `reconcile`
+
+When new information needs to be merged into an existing store `reconcile` can be useful.
+`reconcile` will determine the differences between new and existing data and initiate updates only when there are _changed_ values, thereby avoiding unnecessary updates.
+
+```jsx
+const { createStore, reconcile } from "solid-js/stores"
+
+const [data, setData] = createStore({
+ animals: ['cat', 'dog', 'bird', 'gorilla']
+})
+
+const newData = getNewData() // eg. contains ['cat', 'dog', 'bird', 'gorilla', 'koala']
+setData('animals', reconcile(newData))
+
+```
+
+In this example, the store will look for the differences between the existing and incoming data sets.
+Consequently, only `'koala'` - the new edition - will cause an update.
+
+### Extracting raw data with `unwrap`
+
+When there is a need for dealing with data outside of a reactive context, the `unwrap` utility offers a way to transform a store to a standard [object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object).
+This conversion serves several important purposes.
+
+Firstly, it provides a snapshot of the current state without the processing overhead associated with reactivity.
+This can be useful in situations where an unaltered, non-reactive view of the data is needed.
+Additionally, `unwrap` provides a means to interface with third-party libraries or tools that anticipate regular JavaScript objects.
+This utility acts as a bridge to facilitate smooth integrations with external components and simplifies the incorporation of stores into various applications and workflows.
+
+```jsx
+import { createStore, unwrap } from "solid-js/store"
+
+const [data, setData] = createStore({
+ animals: ["cat", "dog", "bird", "gorilla"],
+})
+
+const rawData = unwrap(data)
+```
+
+To learn more about how to use Stores in practice, visit the [guide on complex state management](/guides/complex-state-management).
+
+
+---
+title: Understanding JSX
+order: 2
+---
+
+JSX is an extension for JavaScript.
+It allows you to write HTML-like code inside your JavaScript file which keeps your rendering logic and content in the same place.
+This provides a concise and readable way to create and represent components.
+
+## How Solid uses JSX
+
+Solid was designed to align closely with HTML standards.
+
+```jsx
+const element =
+When working with JSX, parts of your code are translated into structured HTML that is placed at the start of the file.
+Static elements are processed differently from dynamic ones, which might change based on data or user actions.
+For dynamic elements, special markers are added for better handling during rendering.
+
+Having a single root creates a consistent and manageable hierarchy to optimize rendering and updates.
+
+
+JSX maintains the familiar nested, tree-like structure found in HTML.
+As a result, parent-child relationships between elements become easier to follow.
+
+### Close all tags
+
+Self-closing tags are a must in JSX.
+Unlike in HTML, where elements like ``, `![]()
`, or `
` don't require explicit closure, JSX requires consistent self-closing tags. +This helps to avoid potential rendering issues. + +```jsx +
+```
+
+### Properties vs. attributes
+
+HTML attributes and JSX properties may seem similar, but they serve different purposes and behave differently.
+Both offer ways to specify configurations or pass information.
+However, HTML is used for standard web content and JSX creates Solid's component logic.
+
+#### HTML attributes
+
+[HTML attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes) are values set directly on HTML elements.
+They provide additional information about an element to guide its initial behavior and state.
+These attributes are often translated into properties on DOM objects once the browser parses the HTML.
+
+In JSX files, HTML attributes are used much like regular HTML, with a few key differences due to the blend of HTML and JavaScript:
+
+- Event listeners such as `onClick` can be in camelCase or lowercase.
+ (**Note:** When using ESLint, you will get a warning if you use lowercase.)
+- In cases where you can dynamically specify a value, you can replace the `"` and `"` with curly braces (`{ }`):
+
+```jsx
+
+```
+
+
+ If you wish to pass objects in JSX, such as with inline styling, you will have to use double curly braces (`{{ }}`).
+
+```jsx
+
+```
+
+
+### JSX properties (props)
+
+JSX properties, commonly known as "props," help with the passing of data and configurations to components within an application.
+They connect the component with the data it requires, for seamless data flows and dynamic interactions.
+
+#### Core concepts
+
+- **Static props**:
+ In Solid's JSX, static props are integrated directly into the HTML by cloning the template and using them as attributes.
+
+ - **Dynamic props**:
+ Dynamic props rely on state, allowing the content or properties to be dynamic.
+ An example is changing the style of an element in response to interactions within an application.
+ This can be expressed in the form of signals (`value={value()}`).
+
+- **Data transfer**:
+ Props are also used to fill components with data that comes from resources, like [`createResource`](/reference/basic-reactivity/create-resource) calls.
+ This results in components that react in real-time to data changes.
+
+
+Expressions, whether fixed or dynamic, get applied *in the order defined within the JSX*.
+This works for a wide range of DOM elements, but will not work with elements that require attributes to be defined in a special order, such as input types with `type='range'`.
+
+When order influences an element's behavior, users must define the expressions in the order that the element is expected.
+
+
+For how to use props effectively in Solid, explore the [props page](/concepts/components/props).
+
+
+---
+title: Overview
+mainNavExclude: true
+---
+
+# Overview
+
+Solid is a modern JavaScript framework designed to build responsive and high-performing user interfaces (UI).
+It prioritizes a simple and predictable development experience, making it a great choice for developers of all skill levels.
+
+## What is Solid?
+
+As a JavaScript framework, Solid embraces reactivity and fine-grained updates.
+
+Reactivity, in programming, refers to an applications' ability to respond to changes in data or user interactions.
+
+Traditionally, when a change occurs, the entire web page would need to reload to display the updated information.
+In contrast, when using a fine-grained reactive system, updates are only applied to the parts of the page that need to be updated.
+
+Solid adopts the concept of fine-grained reactivity, updating only when the data the application depends on changes.
+This decreases work and can result in faster load times and a smoother user experience overall.
+
+## Advantages of using Solid
+
+- **Performant**: Fine-grained reactivity allows Solid to update only what has changed, resulting in faster load times and smoother performance overall.
+
+- **Powerful**: Using less memory and processing power, Solid is capable of creating complex applications without compromising on functionality.
+ This also gives developers the flexibility over how and when updates happen.
+
+- **Pragmatic**: Rather than sticking to rigid structures or methods, Solid provides the freedom to choose the strategies and practices that work best for you.
+
+- **Productive**: Regardless of experience level, Solid's clear and predictable API makes developers' work simpler and more efficient.
+
+Solid aims to strike a balance between speed, efficiency, power, and flexibility, all while providing a developer-friendly environment.
+This combination of features makes it a great choice to build responsive and high-performing UIs.
+
+## Quick links
+
+
+
+ - Familiarity with the command line
+ - Install [Node.js](https://nodejs.org/en) or [Deno](https://deno.com)
+
+
+
+Solid offers convenient project templates that can help kickstart your development.
+To get an application running, follow the steps below based on the language you prefer to use.
+
+### For JavaScript projects
+
+1. Run the following command in your terminal to get the JavaScript starter template:
+
+
+
+
+
+2. Navigate to your application's directory:
+
+```bash frame="none"
+cd my-app
+```
+
+3. Install the necessary dependencies:
+
+
+
+
+4. Run the application:
+
+
+
+
+This will start the development server.
+Now, you can open your browser and navigate to `localhost:3000` to see your application running.
+
+### For TypeScript projects
+
+1. To use a TypeScript template, run the following command in your terminal:
+
+
+
+
+2. Navigate to your application's directory:
+
+```bash frame="none"
+cd my-app
+```
+
+3. Install the necessary dependencies:
+
+
+
+
+4. Run the application:
+
+
+
+
+
+This will start the development server.
+Now, you can open your browser and navigate to `localhost:3000` to see your application running.
+
+### Explore more templates
+
+Solid offers a variety of Vite templates to streamline your development process.
+These resources are available on [GitHub](https://github.com/solidjs/templates).
+
+
+---
+title: createEffect
+---
+
+```tsx
+import { createEffect } from "solid-js"
+
+function createEffect(fn: (v: T) => T, value?: T): void
+
+```
+
+Effects are a general way to make arbitrary code ("side effects") run whenever dependencies change, e.g., to modify the DOM manually.
+`createEffect` creates a new computation that runs the given function in a tracking scope, thus automatically tracking its dependencies, and automatically reruns the function whenever the dependencies update.
+
+For example:
+
+```tsx
+const [a, setA] = createSignal(initialValue)
+
+// effect that depends on signal `a`
+createEffect(() => doSideEffect(a()))
+```
+
+The effect will run whenever `a` changes value.
+
+The effect will also run once, immediately after it is created, to initialize the DOM to the correct state. This is called the "mounting" phase.
+However, we recommend using `onMount` instead, which is a more explicit way to express this.
+
+The effect callback can return a value, which will be passed as the `prev` argument to the next invocation of the effect.
+This is useful for memoizing values that are expensive to compute. For example:
+
+```tsx
+const [a, setA] = createSignal(initialValue)
+
+// effect that depends on signal `a`
+createEffect((prevSum) => {
+ // do something with `a` and `prevSum`
+ const sum = a() + b()
+ if (sum !== prevSum) console.log("sum changed to", sum)
+ return sum
+}, 0)
+// ^ the initial value of the effect is 0
+```
+
+Effects are meant primarily for side effects that read but don't write to the reactive system: it's best to avoid setting signals in effects, which without care can cause additional rendering or even infinite effect loops. Instead, prefer using [createMemo](/reference/basic-reactivity/create-memo) to compute new values that depend on other reactive values, so the reactive system knows what depends on what, and can optimize accordingly.
+If you do end up setting a signal within an effect, computations subscribed to that signal will be executed only once the effect completes; see [`batch`](/reference/reactive-utilities/batch) for more detail.
+
+The first execution of the effect function is not immediate; it's scheduled to run after the current rendering phase (e.g., after calling the function passed to [render](/reference/rendering/render), [createRoot](/reference/reactive-utilities/create-root), or [runWithOwner](/reference/reactive-utilities/run-with-owner)).
+If you want to wait for the first execution to occur, use [queueMicrotask](https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask) (which runs before the browser renders the DOM) or `await Promise.resolve()` or `setTimeout(..., 0)` (which runs after browser rendering).
+
+```tsx
+// assume this code is in a component function, so is part of a rendering phase
+const [count, setCount] = createSignal(0)
+
+// this effect prints count at the beginning and when it changes
+createEffect(() => console.log("count =", count()))
+// effect won't run yet
+console.log("hello")
+setCount(1) // effect still won't run yet
+setCount(2) // effect still won't run yet
+
+queueMicrotask(() => {
+ // now `count = 2` will print
+ console.log("microtask")
+ setCount(3) // immediately prints `count = 3`
+ console.log("goodbye")
+})
+
+// --- overall output: ---
+// hello
+// count = 2
+// microtask
+// count = 3
+// goodbye
+```
+
+This delay in first execution is useful because it means an effect defined in a component scope runs after the JSX returned by the component gets added to the DOM.
+In particular, [refs](/reference/jsx-attributes/ref) will already be set.
+Thus you can use an effect to manipulate the DOM manually, call vanilla JS libraries, or other side effects.
+
+Note that the first run of the effect still runs before the browser renders the DOM to the screen (similar to React's `useLayoutEffect`).
+If you need to wait until after rendering (e.g., to measure the rendering), you can use `await Promise.resolve()` (or `Promise.resolve().then(...)`), but note that subsequent use of reactive state (such as signals) will not trigger the effect to rerun, as tracking is not possible after an async function uses `await`.
+Thus you should use all dependencies before the promise.
+
+If you'd rather an effect run immediately even for its first run, use [createRenderEffect](/reference/secondary-primitives/create-render-effect) or [createComputed](/reference/secondary-primitives/create-computed).
+
+You can clean up your side effects in between executions of the effect function by calling [onCleanup](/reference/lifecycle/on-cleanup) inside the effect function.
+Such a cleanup function gets called both in between effect executions and when the effect gets disposed (e.g., the containing component unmounts).
+For example:
+
+```tsx
+// listen to event dynamically given by eventName signal
+createEffect(() => {
+ const event = eventName()
+ const callback = (e) => console.log(e)
+ ref.addEventListener(event, callback)
+ onCleanup(() => ref.removeEventListener(event, callback))
+})
+```
+
+## Arguments
+
+- `fn` - The function to run in a tracking scope. It can return a value, which will be passed as the `prev` argument to the next invocation of the effect.
+- `value` - The initial value of the effect. This is useful for memoizing values that are expensive to compute.
+
+
+---
+title: createMemo
+---
+
+Memos let you efficiently use a derived value in many reactive computations.
+`createMemo` creates a readonly reactive value equal to the return value of the given function and makes sure that function only gets executed when its dependencies change.
+
+```tsx
+import { createMemo } from "solid-js"
+
+function createMemo(
+ fn: (v: T) => T,
+ value?: T,
+ options?: { equals?: false | ((prev: T, next: T) => boolean) }
+): () => T
+
+```
+
+Here's an example of how createMemo can be used:
+
+```ts
+const value = createMemo(() => computeExpensiveValue(a(), b()))
+
+//read the value
+value()
+```
+
+In Solid, you often don't need to wrap functions in memos; you can alternatively just define and call a regular function to get similar reactive behavior.
+The main difference is when you call the function in multiple reactive settings.
+In this case, when the function's dependencies update, the function will get called multiple times unless it is wrapped in createMemo.
+For example:
+
+```tsx
+const user = createMemo(() => searchForUser(username()))
+// compare with: const user = () => searchForUser(username());
+return (
+ (value: T): Signal {
+ const [store, setStore] = createStore({
+ value,
+ })
+ return [
+ () => store.value,
+ (v: T) => {
+ const unwrapped = unwrap(store.value)
+ typeof v === "function" && (v = v(unwrapped))
+ setStore("value", reconcile(v))
+ return store.value
+ },
+ ] as Signal
+}
+
+const [resource] = createResource(fetcher, {
+ storage: createDeepSignal,
+})
+```
+
+This option is still experimental and may change in the future.
+
+## Options
+
+The `createResource` function takes an optional third argument, an options object. The options are:
+
+| Name | Type | Default | Description |
+| ------------ | ----------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| name | `string` | `undefined` | A name for the resource. This is used for debugging purposes. |
+| deferStream | `boolean` | `false` | If true, Solid will wait for the resource to resolve before flushing the stream. |
+| initialValue | `any` | `undefined` | The initial value of the resource. |
+| onHydrated | `function` | `undefined` | A callback that is called when the resource is hydrated. |
+| ssrLoadFrom | `"server" \| "initial"` | `"server"` | The source of the initial value for SSR. If set to `"initial"`, the resource will use the `initialValue` option instead of the value returned by the fetcher. |
+| storage | `function` | `createSignal` | A function that returns a signal. This can be used to create a custom storage for the resource. This is still experimental |
+
+## Note for TypeScript users
+
+The function and type definitions for `createResource` are as follows:
+
+```tsx
+import { createResource } from "solid-js"
+import type { ResourceReturn, ResourceOptions } from "solid-js"
+
+type ResourceReturn = [
+ {
+ (): T | undefined
+ state: "unresolved" | "pending" | "ready" | "refreshing" | "errored"
+ loading: boolean
+ error: any
+ latest: T | undefined
+ },
+ {
+ mutate: (v: T | undefined) => T | undefined
+ refetch: (info: unknown) => Promise | T
+ }
+]
+
+type ResourceOptions = {
+ initialValue?: T
+ name?: string
+ deferStream?: boolean
+ ssrLoadFrom?: "initial" | "server"
+ storage?: (
+ init: T | undefined
+ ) => [Accessor, Setter]
+ onHydrated?: (k: S | undefined, info: { value: T | undefined }) => void
+}
+
+function createResource(
+ fetcher: (
+ k: U,
+ info: { value: T | undefined; refetching: boolean | unknown }
+ ) => T | Promise,
+ options?: ResourceOptions
+): ResourceReturn
+
+function createResource(
+ source: U | false | null | (() => U | false | null),
+ fetcher: (
+ k: U,
+ info: { value: T | undefined; refetching: boolean | unknown }
+ ) => T | Promise,
+ options?: ResourceOptions
+): ResourceReturn
+
+```
+
+
+---
+title: createSignal
+---
+
+Signals are the most basic reactive primitive.
+They track a single value (which can be a value of any type) that changes over time.
+
+```tsx
+import { createSignal } from "solid-js"
+
+function createSignal(
+ initialValue: T,
+ options?: {
+ equals?: false | ((prev: T, next: T) => boolean)
+ name?: string
+ internal?: boolean
+ }
+): [get: () => T, set: (v: T) => T]
+
+// available types for return value of createSignal:
+import type { Signal, Accessor, Setter } from "solid-js"
+type Signal = [get: Accessor, set: Setter]
+type Accessor = () => T
+type Setter = (v: T | ((prev?: T) => T)) => T
+
+```
+
+The Signal's value starts out equal to the passed first argument `initialValue` (or undefined if there are no arguments).
+The `createSignal` function returns a pair of functions as a two-element array: a getter (or accessor) and a setter.
+In typical use, you would destructure this array into a named Signal like so:
+
+```tsx
+const [count, setCount] = createSignal(0)
+const [ready, setReady] = createSignal(false)
+```
+
+Calling the getter (e.g., `count()` or `ready()`) returns the current value of the Signal.
+
+Crucial to automatic dependency tracking, calling the getter within a tracking scope causes the calling function to depend on this Signal, so that function will rerun if the Signal gets updated.
+
+Calling the setter (e.g., `setCount(nextCount)` or `setReady(nextReady)`) sets the Signal's value and updates the Signal (triggering dependents to rerun) if the value actually changed (see details below).
+The setter takes either the new value for the signal or a function that maps the previous value of the signal to a new value as its only argument.
+The updated value is also returned by the setter. As an example:
+
+```tsx
+// read signal's current value, and
+// depend on signal if in a tracking scope
+// (but nonreactive outside of a tracking scope):
+const currentCount = count()
+
+// or wrap any computation with a function,
+// and this function can be used in a tracking scope:
+const doubledCount = () => 2 * count()
+
+// or build a tracking scope and depend on signal:
+const countDisplay =
+ If you want to store a function in a Signal you must use the function form:
+
+ ```tsx
+ setValue(() => myFunction);
+ ```
+
+ However, functions are not treated specially as the `initialValue` argument to `createSignal`, so you can pass a
+ function initial value as is:
+
+ ```tsx
+ const [func, setFunc] = createSignal(myFunction);
+ ```
+
+
+
+## Options
+
+| Name | Type | Default | Description |
+| ---------- | ------------------------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `equals` | `false \| ((prev: T, next: T) => boolean)` | `===` | A function that determines whether the Signal's value has changed. If the function returns true, the Signal's value will not be updated and dependents will not rerun. If the function returns false, the Signal's value will be updated and dependents will rerun. |
+| `name` | `string` | | A name for the Signal. This is useful for debugging. |
+| `internal` | `boolean` | `false` | If true, the Signal will not be accessible in the devtools. |
+
+### `equals`
+
+The `equals` option can be used to customize the equality check used to determine whether the Signal's value has changed.
+By default, the equality check is a strict equality check (`===`).
+If you want to use a different equality check, you can pass a custom function as the `equals` option.
+The custom function will be called with the previous and next values of the Signal as arguments.
+If the function returns true, the Signal's value will not be updated and dependents will not rerun.
+If the function returns false, the Signal's value will be updated and dependents will rerun.
+
+```tsx
+const [count, setCount] = createSignal(0, {
+ equals: (prev, next) => prev === next,
+})
+```
+
+Here are some examples of this option in use:
+
+```tsx
+// use { equals: false } to allow modifying object in-place;
+// normally this wouldn't be seen as an update because the
+// object has the same identity before and after change
+const [object, setObject] = createSignal({ count: 0 }, { equals: false })
+setObject((current) => {
+ current.count += 1
+ current.updated = new Date()
+ return current
+})
+
+// use { equals: false } to create a signal that acts as a trigger without storing a value:
+const [depend, rerun] = createSignal(undefined, { equals: false })
+// now calling depend() in a tracking scope
+// makes that scope rerun whenever rerun() gets called
+
+// define equality based on string length:
+const [myString, setMyString] = createSignal("string", {
+ equals: (newVal, oldVal) => newVal.length === oldVal.length,
+})
+
+setMyString("string") // considered equal to the last value and won't cause updates
+setMyString("stranger") // considered different and will cause updates
+```
+
+### `name`
+
+The `name` option can be used to give the Signal a name.
+This is useful for debugging. The name will be displayed in the devtools.
+
+```tsx
+const [count, setCount] = createSignal(0, { name: "count" })
+```
+
+### `internal`
+
+The `internal` option can be used to hide the Signal from the devtools.
+This is useful for Signals that are used internally by a component and should not be exposed to the user.
+
+```tsx
+const [count, setCount] = createSignal(0, { internal: true })
+```
+
+
+---
+title: children
+---
+
+```tsx
+import { children } from "solid-js";
+import type { JSX, ResolvedChildren } from "solid-js";
+
+function children(fn: () => JSX.Element): () => ResolvedChildren
+
+```
+
+The `children` helper is used for more complex interactions with props.
+When you're not just passing children to another component using `props.children` once in JSX, you should use `children`.
+Props are normally passed in via a getter for `props.children` in this manner:
+
+```tsx
+const resolved = children(() => props.children)
+```
+
+The return value is a [memo](/reference/basic-reactivity/create-memo) evaluating to the resolved children, which updates whenever the children change.
+Using this memo instead of accessing `props.children` directly has some important advantages in some scenarios.
+The underlying issue is that, when you specify component children via JSX, Solid automatically defines `props.children` as a property getter, so that the children are created (in particular, DOM is created) whenever `props.children` gets accessed.
+
+Two particular consequences:
+
+1. If you access `props.children` multiple times, the children (and associated DOM) get created multiple times.
+This is useful if you want the DOM to be duplicated (as DOM nodes can appear in only one parent element), but in many cases it creates redundant DOM nodes.
+If you instead call `resolved()` multiple times, you re-use the same children.
+
+2. If you access `props.children` outside of a tracking scope (e.g., in an event handler), then you create children that will never be cleaned up.
+If you instead call `resolved()`, you re-use the already resolved children.
+You also guarantee that the children are tracked in the current component, as opposed to another tracking scope such as another component.
+
+In addition, the `children` helper "resolves" children by calling argumentless functions and flattening arrays of arrays into an array.
+For example, a child specified with JSX like `{signal() * 2}` gets wrapped into a getter function `() => count() * 2` in `props.children`, but gets evaluated to an actual number in resolved, properly depending on a count signal.
+
+If the given `props.children` is not an array (which occurs when the JSX tag has a single child), then the `children` helper will not normalize it into an array.
+This is useful behavior e.g. when the intention is to pass a single function as a child, which can be detected via `typeof resolved() === 'function'`.
+If you want to normalize to an array, the returned memo has a `toArray` method _(new in 1.5)_.
+
+In most cases, you don't need (and in some cases, don't want) to use the `children` helper if you're just passing `props.children` on to another component or element via JSX:
+
+```tsx
+const Wrapper = (props) => {
+ return `](/reference/components/show) component.
+For example, the following code always evaluates the children:
+
+```tsx
+const resolved = children(() => props.children)
+
+return {resolved()}
+```
+
+To evaluate the children only when `` would render them, you can push the call to children inside a component or a function within ``, which only evaluates its children when `when` condition is true.
+Another nice workaround is to pass `props.children` to the children helper only when you actually want to evaluate the children:
+
+```tsx
+const resolved = children(() => visible() && props.children)
+```
+
+
+---
+title: createContext
+order: 5
+---
+
+
+Context provides a form of dependency injection in Solid.
+It is used to save from needing to pass data as props through intermediate components (aka** prop drilling**).
+This function creates a new context object that can be used with [useContext](/reference/component-apis/use-context) and offers the Provider control flow.
+The default value is used when no Provider is found above in the hierarchy.
+
+## Usage
+
+To avoid reinstatiating a new context when Hot-Module Replacement (HMR) occurs, it is recommended to use `createContext` in its own module (file).
+
+
+When using HMR, the context is lost when the module is reloaded. Which will cause an error to be thrown as `useContext` will try to access it while it is still reloading.
+
+
+
+For example:
+
+```ts title="/context/counter.ts"
+import { createContext } from "solid-js";
+
+export const INITIAL_COUNT = 0;
+
+const INITIAL_STORE_SETTER = {
+ increment: () => {},
+ decrement: () => {}
+};
+
+export const CounterContext = createContext([
+ { count: INITIAL_COUNT },
+ INITIAL_STORE_SETTER
+]);
+```
+
+With the context created in its own module, you can use to instantiate the context provider.
+
+```ts title="/context/counter-component.tsx"
+import { createStore } from 'solid-js/store';
+import { CounterContext, INITIAL_COUNT } from "./counter.ts";
+
+export function CounterProvider(props) {
+ const [value, setValue] = createStore({ count: props.initialCount || INITIAL_COUNT })
+
+ const counter = [
+ value,
+ {
+ increment() {
+ setValue("count", currentCount => currentCount + 1)
+ },
+ decrement() {
+ setValue("count", currentCount => currentCount - 1)
+ },
+ },
+ ]
+
+ return (
+
+ {props.children}
+
+ )
+}
+```
+
+A few imporant notes on how to pass data through the context API:
+
+- The value passed to provider is passed to `useContext` as is.
+- Wrapping as a reactive expression will not work.
+- You should pass in Signals and Stores directly instead of accessing them in the JSX.
+
+To learn how to consume the context, see the [useContext](/reference/component-apis/use-context) documentation and the [Context concepts entry](/concepts/context).
+
+## Default Values
+
+`createContext()` takes an optional "default value" as an argument.
+If `useContext` is called and there is no corresponding context provider above it in the component hierarchy, then the value passed as `defaultValue` is returned.
+
+However, if no `defaultValue` was passed, then `undefined` is returned in this case.
+Also, `defaultValue` (or `undefined`) is returned if `useContext` is called inside an event callback, as it is then outside of the component hierarchy.
+
+This has implications for TS.
+If no `defaultValue` is passed, then it is possible that `useContext()` will return `undefined`, and the types reflect this.
+
+Another (used in the example in the previous section) is provide a default value to `createContext()`.
+In that case, `useContext()` will always return a value, and therefore TS will not complain either.
+The pitfall with this approach is that if you _unintentionally_ use `useContext` outside of a provider, it may not be immediately apparent, because the context is still providing a valid value.
+Therefore, if you expect to always use `useContext` within a provider, it is best to use the error based approach described above.
+
+## Type signature
+
+```ts
+interface Context {
+ id: symbol
+ Provider: (props: { value: T; children: any }) => any
+ defaultValue: T
+}
+
+function createContext(defaultValue?: T): Context
+```
+
+
+---
+title: createUniqueId
+---
+
+```ts
+import { createUniqueId } from "solid-js"
+
+function createUniqueId(): string
+
+```
+
+A universal id generator that is stable across server/browser.
+
+```ts
+const id = createUniqueId()
+```
+
+**Note:** on the server this only works under hydratable components.
+
+
+---
+title: lazy
+---
+
+```ts
+import { lazy } from "solid-js"
+import type { Component } from "solid-js"
+
+function lazy>(
+ fn: () => Promise<{ default: T }>
+): T & { preload: () => Promise }
+```
+
+Used to lazy load components to allow for code splitting.
+Components are not loaded until rendered.
+Lazy loaded components can be used the same as its statically imported counterpart, receiving props etc.
+Lazy components trigger ``
+
+```tsx
+// wrap import
+const ComponentA = lazy(() => import("./ComponentA"));
+
+// use in JSX
+(context: Context): T
+
+```
+
+---
+title:
+order: 5
+---
+
+This component lets you insert an arbitrary Component or tag and passes the props through to it.
+
+```tsx
+import { Dynamic } from "solid-js/web"
+import type { JSX } from "solid-js"
+
+function Dynamic(
+ props: T & {
+ children?: any
+ component?: Component | string | keyof JSX.IntrinsicElements
+ }
+): () => JSX.Element
+```
+
+Here's an example of how you can use it:
+
+```tsx
+` \| `string` \| `keyof JSX.IntrinsicElements` | The component to render. |
+| `children` | `any` | The children to pass to the component. |
+| `...` | `T` | Any other props to pass to the component. |
+
+
+---
+title:
+order: 5
+---
+
+Catches uncaught errors and renders fallback content.
+
+```tsx
+import { ErrorBoundary } from "solid-js"
+import type { JSX } from "solid-js"
+
+function ErrorBoundary(props: {
+ fallback: JSX.Element | ((err: any, reset: () => void) => JSX.Element)
+ children: JSX.Element
+}): () => JSX.Element
+```
+
+Here's an example of how to use it:
+
+```tsx
+Something went terribly wrong
}>
+ ...
;
+}
+```
+
+`onMount` provides the assurance that the callback will only run once.
+If using an effect in this situation, there is no guarantee that it will only run once, which can lead to unexpected behaviour.
+This makes `onMount` useful for API calls and other side effects that only need to be run once per component instance.
+
+### `onCleanup`
+
+While `onMount` is useful for running a side effect once, [`onCleanup`](/reference/lifecycle/on-cleanup) is helpful for cleaning up a task when it is no longer needed.
+`onCleanup` will run whenever the component unmounts, removing any subscriptions that the effect has.
+
+```jsx
+import { onCleanup } from "solid-js";
+
+function App() {
+ const [count, setCount] = createSignal(0);
+
+ const timer = setInterval(() => {
+ setCount((prev) => prev + 1);
+ }, 1000);
+
+ onCleanup(() => {
+ clearInterval(timer);
+ });
+
+ return Count: {count()}
;
+}
+```
+
+In this example, the `onCleanup` function is used to clear the interval that is set up in the effect.
+To avoid the interval from running indefinitely, the `onCleanup` function is used to clear the interval once the component unmounts.
+
+`onCleanup` can be used to avoid memory leaks.
+These occur when a component is unmounted, but references to it still exist and, as a result, could still be running in the background.
+Using `onCleanup` to remove any subscriptions or references to the component can help to avoid this issue.
+
+
+---
+title: "Intro to reactivity"
+order: 1
+---
+
+**Note**: While this guide is useful for understanding reactive systems, it does use some Solid-specific terminology.
+
+Reactivity powers the interactivity in Solid applications.
+This programming paradigm refers to a system's ability to respond to changes in data or state automatically.
+With Solid, reactivity is the basis of its design, ensuring application's stay up-to-date with its underlying data.
+
+## Importance of reactivity
+
+1. Reactivity keeps the user interface (UI) and state in sync, which reduces the need for manual updates.
+
+2. Real-time updates create a more responsive and interactive user experience.
+
+```jsx
+function Counter() {
+ const [count, setCount] = createSignal(0);
+ const increment = () => setCount((prev) => prev + 1);
+
+ return (
+
+ Count: {count()}{" "}
+ {/* Only `count()` is updated when the button is clicked. */}
+
+
+ );
+}
+```
+
+This `Counter` function sets up a button that, when clicked, calls the `increment` function to increase the `count` by one.
+This updates just the number displayed _without_ refreshing the entire component.
+
+
+ Count: {count()}{" "}
+ {/* ✅ will update when `count()` changes. */}
+
+
+ );
+}
+```
+
+Components, much like other functions, will only run _once_.
+This means that if a signal is accessed outside of the return statement, it will run on initialization, but any updates to the signal will not trigger an update.
+
+```jsx
+function Counter() {
+ const [count, setCount] = createSignal(0);
+ const increment = () => setCount((prev) => prev + 1);
+
+ console.log("Count:", count()); // ❌ not tracked - only runs once during initialization.
+
+ createEffect(() => {
+ console.log(count()); // ✅ will update whenever `count()` changes.
+ });
+
+ return (
+
+ Count: {count()}{/* ✅ will update whenever `count()` changes. */}
+
+
+ );
+}
+```
+
+To learn more about managing state in Solid, visit the [guide on state management](/guides/state-management).
+
+## Synchronous vs. asynchronous
+
+Reactive systems are designed to respond to changes in data.
+These responses can be immediate or delayed, depending on the nature of the system.
+Often, the choice between these two depends on the requirements of the application and the nature of the tasks involved.
+
+### Synchronous reactivity
+
+[Synchronous](https://developer.mozilla.org/en-US/docs/Glossary/Synchronous) reactivity is Solid's default reactivity mode, where a system responds to changes in a direct and linear fashion.
+When a signal changes, any corresponding subscribers are immediately updated in an ordered manner.
+
+With synchronous reactivity, the system is able to respond to changes in a predictable manner.
+This is useful in scenarios where the order of updates is important.
+For example, if a subscriber depends on another signal, it is important that the subscriber is updated after the signal it depends on.
+
+```jsx
+const [count, setCount] = createSignal(0);
+const [double, setDouble] = createSignal(0);
+
+createEffect(() => {
+ setDouble(count() * 2);
+});
+```
+
+In this example, the `double` signal will always be updated after `count` due to synchronous reactivity.
+This ensures that `double` is always up-to-date with the latest value of `count`.
+
+### Asynchronous reactivity
+
+[Asynchronous](https://developer.mozilla.org/en-US/docs/Glossary/Asynchronous) reactivity is when a system responds to changes in a delayed or non-linear fashion.
+When a signal changes, the corresponding subscribers are not immediately updated.
+Instead, the system waits for a specific event or task to complete before updating the subscribers.
+
+This is important in scenarios where subscribers depend on multiple signals.
+In these cases, updating one signal before another could result in data inconsistency.
+For example, if a subscriber depends on two signals, it is important that the subscriber is updated after both signals have been updated.
+Rather, the system waits for both signals to be updated before updating the subscriber.
+
+**Note:** When asynchronous reactivity is present, it is important to ensure that the system is able to handle the delay in updates.
+[`batch`](/reference/reactive-utilities/batch) can be used to delay an update so the subscriber runs after each signal has been updated.
+
+## Key concepts
+
+- Signals are the core elements of a reactive system.
+ They are responsible for storing and managing data.
+- Signals are both readable and writeable because of getters and setters.
+- Subscribers are automated responders that track changes in signals and update the system accordingly.
+- Signals and subscribers work together to ensure that the system is kept up-to-date with the latest data changes.
+- A reactive system is built on the principles of data-driven reactivity.
+ This means that the system's reactivity is driven by the data it is built on.
+- Reactive systems can be synchronous or asynchronous.
+
+If you want to dive deeper, visit the [guide on fine-grained reactivity](/advanced-concepts/fine-grained-reactivity).
+
+
+---
+title: Refs
+---
+
+Refs, or references, are a special attribute that can be attached to any element, and are used to reference a DOM element or a component instance.
+They are particularly useful when you need to access the DOM nodes directly or invoke methods on a component.
+
+## Accessing DOM elements
+
+One way of accessing DOM elements is through [element selectors](https://developer.mozilla.org/en-US/docs/Web/API/Document_object_model/Locating_DOM_elements_using_selectors) such as [`document.querySelector`](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector) or [`document.getElementById`](https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById).
+Since elements in Solid can be added or removed from the DOM based on state, you need to wait until the element is attached to the DOM before accessing it.
+This can be done by using [`onMount`](/reference/lifecycle/on-mount) to wait until the element is attached to the DOM before accessing it:
+
+Accessing DOM elements through element selectors is not recommended for this reason.
+As elements with the same selectors are added and removed from the DOM, the first element that matches the selector will be returned, which may not be the element you want.
+
+## JSX as a value
+
+JSX can be used as a value and assigned to a variable when looking to directly access DOM elements.
+
+```tsx
+function Component() {
+ const myElement = My Element
+ + return{myElement}
+}
+```
+
+This lets you create and access DOM elements similar to [`document.createElement`](https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement) but without having to wait until it is attached to the DOM.
+It can be used multiple times without having to worry about duplicate selectors.
+
+The downside of this approach is that it separates the element and any child elements from the rest of the JSX structure.
+This makes the component's JSX structure more difficult to read and understand.
+
+## Refs in Solid
+
+Solid provides a ref system to access DOM elements directly inside the JSX template, which keeps the structure of the elements intact.
+
+To use [`ref`](/reference/jsx-attributes/ref), you declare a variable and use it as the `ref` attribute:
+
+```tsx {6}
+function Component() {
+ let myElement;
+
+ return (
+
+
+ )
+}
+```
+
+These assignments occur at _creation time_ prior to the element being added to the DOM.
+If access to an element is needed before it is added to the DOM, you can use the callback form of `ref`:
+
+```jsx
+My Element
+{ + myElement = el // el is created but not yet added to the DOM + }}> + My Element +
+``` + +
+
+
+
+
+
+ )
+}
+```
+
+In this example, the paragraph element is only rendered when the `show` signal is `true`.
+When the component initializes, the paragraph element does not exist, so the `element` variable is not assigned.
+Once the `show` signal is set to `true`, the paragraph element is rendered, and the `element` variable is assigned to the paragraph element.
+
+You can see a detailed view of the ref update lifecycle in this [Solid playground example](https://playground.solidjs.com/anonymous/22a1abfa-a0f5-44a6-bbe6-40387cf63b95).
+
+## Forwarding refs
+
+Forwarding refs is a technique that allows you to pass a ref from a parent component to a child component.
+This is useful when you want to access the DOM element of a child component from the parent component.
+
+To forward a ref, you need to pass the ref to the child component, and then assign the ref to the child component's element.
+
+When a child component receives a `ref` attribute from its parent, the `ref` is passed as a callback function.
+This is regardless of whether the parent passed it as a simple assignment or a callback.
+
+Once the child component receives the `ref`, it can be assigned to the element that the child component wants to expose through the `ref` attribute.
+To access the `ref` in the child component, it is passed as a prop:
+
+```tsx
+// Parent component
+import { Canvas } from "./Canvas.jsx"
+
+function ParentComponent() {
+ let canvasRef
+
+ const animateCanvas = () => {
+ // Manipulate the canvas using canvasRef...
+ }
+
+ return (
+ This is the ref element
+
+
+
+
+ )
+}
+
+// Child component
+function Canvas(props) {
+ return (
+
+ {/* Assign the ref to the canvas element */}
+
+ )
+}
+```
+
+In this example, the `canvas` element is directly assigned the `ref` attribute through the `props.ref` variable.
+This forwards the reference to the parent component, giving it direct access to the `canvas` element.
+
+## Directives
+
+Directives allow the attachment of reusable behaviours to DOM elements.
+The [`use:`](/reference/jsx-attributes/use) prefix is used to denote these custom directives.
+Unlike props or attributes, directives operate at a lower level through providing fine-grained control over the elements they are attached to.
+
+Directives are like callback refs but they enable two extra features:
+
+- Having multiple directives on an element.
+- Passing in reactive data to the callback.
+
+A directive is essentially a function with a specific signature:
+
+```typescript
+function directive(element: Element, accessor: () => any): void
+
+```
+
+- `element`: The DOM element that the directive is applied to.
+- `accessor`: A function that gives access to the value(s) passed to the directive.
+
+The directive functions are called at render time, but are called before the element is added to the DOM.
+Due to this order, elements are fully primed with their attributes, properties, or event listeners, therefore minimizing unexpected behaviors or premature interactions.
+
+Within directives, you're able to perform a variety of tasks, including:
+
+- creating [signals](/concepts/signals)
+- initiating [effects](/guides/state-management#reacting-to-changes)
+- adding [event listeners](/concepts/components/event-handlers)
+- and more.
+
+To learn more about directives and how they work with TypeScript, refer to our [TypeScript for Solid guide](/configuration/typescript).
+
+
+---
+title: Signals
+order: 2
+---
+
+Signals are the primary means of [managing state](/concepts/intro-to-reactivity#state-management) in your Solid application.
+They provide a way to store and update values, and are the foundation of [reactivity](/concepts/intro-to-reactivity) in Solid.
+
+Signals can be used to represent any kind of state in your application, such as the current user, the current page, or the current theme.
+This can be any value, including primitive values such as strings and numbers, or complex values such as objects and arrays.
+
+## Creating a signal
+
+You can create a signal by calling the [`createSignal`](/reference/basic-reactivity/create-signal) function, which is imported from `solid-js`.
+This function takes an initial value as an argument, and returns a pair of functions: a **getter** function, and a **setter** function.
+
+```jsx
+import { createSignal } from "solid-js";
+
+const [count, setCount] = createSignal(0);
+// ^ getter ^ setter
+```
+
+
+ Count: {count()} {/* Updates when `count` changes */}
+
+
+ );
+}
+```
+
+
+
+ )
+}
+```
+
+When a store is created, it starts with the initial state but does _not_ immediately set up signals to track changes.
+These signals are created **lazily**, meaning they are only formed when accessed within a reactive context.
+
+Once data is used within a reactive context, such as within the return statement of a component function, computed property, or an effect, a signal is created and dependencies are established.
+
+For example, if you wanted to print out every new user, adding the console log below will not work because it is not within a tracked scope.
+
+
+```tsx ins={9}
+const App = () => {
+ const [store, setStore] = createStore({
+ userCount: 3,
+ users: [ ... ],
+ })
+
+ const addUser = () => { ... }
+
+ console.log(store.users.at(-1)) // This won't work
+
+ return (
+ Hello, {store.users[0].username}
{/* Accessing a store value */} + {mySignal()} {/* Accessing a signal */} +
+
+ )
+}
+```
+
+Rather, this would need to be in a tracking scope, like inside a [`createEffect`](/reference/basic-reactivity/create-effect), so that a dependency is established.
+
+```tsx del={9} ins={10-12}
+const App = () => {
+ const [store, setStore] = createStore({
+ userCount: 3,
+ users: [ ... ],
+ })
+
+ const addUser = () => { ... }
+
+ console.log(store.users.at(-1))
+ createEffect(() => {
+ console.log(store.users.at(-1))
+ })
+
+ return (
+ Hello, {store.users[0].username}
+User count: {store.userCount}
+ +
+
+ )
+}
+```
+
+## Modifying store values
+
+Updating values within a store is best accomplished using a setter provided by the `createStore` initialization.
+This setter allows for the modification of a specific key and its associated value, following the format `setStore(key, newValue)`:
+
+```jsx "setStore"
+const [store, setStore] = createStore({
+ userCount: 3,
+ users: [ ... ],
+})
+
+setStore("users", (currentUsers) => [
+ ...currentUsers,
+ {
+ id: 3,
+ username: "michael584",
+ location: "Nigeria",
+ loggedIn: false,
+ },
+])
+```
+
+The value of `userCount` could also be automatically updated whenever a new user is added to keep it synced with the users array:
+
+```tsx ins={11}
+const App = () => {
+ const [store, setStore] = createStore({
+ userCount: 3,
+ users: [ ... ],
+ })
+
+ const addUser = () => { ... }
+
+ createEffect(() => {
+ console.log(store.users.at(-1))
+ setStore("userCount", store.users.length)
+ })
+
+ return (
+ Hello, {store.users[0].username}
+User count: {store.userCount}
+ +
+
+ )
+}
+```
+
+Hello, {store.users[0].username}
+User count: {store.userCount}
+ +I'm JSX!!
+``` + +It offers a distinct advantage, however: to copy/paste solutions from resources like Stack Overflow; and to allow direct usage of templates from design tools. +Solid sets itself apart by using JSX immediately as it returns [DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction) elements. +This lets you use dynamic expressions within your HTML by allowing variables and functions to be references with the use of curly braces (`{ }`): + +```jsx +const Component = () => { + const animal = { breed: "cat", name: "Midnight" } + + return ( ++ I have a {animal.breed} named {animal.name}! +
+ ) +} +``` + +This means JavaScript content can be rendered on web pages based on an application's state or logic. + +Additionally, Solid's [reactive](/concepts/intro-to-reactivity) system introduces [fine-grained reactivity](/advanced-concepts/fine-grained-reactivity) with JSX. +This updates only the necessary parts of the DOM when changes occur in the underlying state. + +## Using JSX in Solid + +### Return a single root element + +Where HTML lets you have disconnected tags at the top level, JSX requires that a component to return a single root element. + +` don't require explicit closure, JSX requires consistent self-closing tags. +This helps to avoid potential rendering issues. + +```jsx +
+```
+
+### Properties vs. attributes
+
+HTML attributes and JSX properties may seem similar, but they serve different purposes and behave differently.
+Both offer ways to specify configurations or pass information.
+However, HTML is used for standard web content and JSX creates Solid's component logic.
+
+#### HTML attributes
+
+[HTML attributes](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes) are values set directly on HTML elements.
+They provide additional information about an element to guide its initial behavior and state.
+These attributes are often translated into properties on DOM objects once the browser parses the HTML.
+
+In JSX files, HTML attributes are used much like regular HTML, with a few key differences due to the blend of HTML and JavaScript:
+
+- Event listeners such as `onClick` can be in camelCase or lowercase.
+ (**Note:** When using ESLint, you will get a warning if you use lowercase.)
+- In cases where you can dynamically specify a value, you can replace the `"` and `"` with curly braces (`{ }`):
+
+```jsx
+
+```
+
+
+
+ Learn the basics of Solid through this interactive tutorial.
+
+
+ Start your first project with a template that fits your needs.
+
+
+ Explore the Solid ecosystem and find useful tools and libraries.
+
+
+ Help improve Solid by contributing to the documentation.
+
+
+
+_Find our API documentation under the **Reference** tab_
+
+Join the [Solid community on Discord](https://discord.com/invite/solidjs) to share your projects or get help from our community!
+
+
+```bash frame="none"
+npx degit solidjs/templates/js my-app
+```
+
+
+
+```bash frame="none"
+yarn dlx degit solidjs/templates/js my-app
+```
+
+
+
+```bash frame="none"
+pnpm dlx degit solidjs/templates/js my-app
+```
+
+
+
+```bash frame="none"
+bunx degit solidjs/templates/js my-app
+```
+
+
+
+```bash frame="none"
+deno -A npm:degit solidjs/templates/js my-app
+```
+
+
+```bash frame="none"
+npm install
+```
+
+
+
+```bash frame="none"
+yarn install
+```
+
+
+
+```bash frame="none"
+pnpm install
+```
+
+
+
+```bash frame="none"
+bun install
+```
+
+
+
+```bash frame="none"
+deno install
+```
+
+
+```bash frame="none"
+npm run dev
+```
+
+
+
+```bash frame="none"
+yarn dev
+```
+
+
+
+```bash frame="none"
+pnpm dev
+```
+
+
+
+```bash frame="none"
+bun dev
+```
+
+
+```bash frame="none"
+deno task dev
+```
+
+
+```bash frame="none"
+npx degit solidjs/templates/ts my-app
+```
+
+
+
+```bash frame="none"
+yarn dlx degit solidjs/templates/ts my-app
+```
+
+
+
+```bash frame="none"
+pnpm dlx degit solidjs/templates/ts my-app
+```
+
+
+
+```bash frame="none"
+bunx degit solidjs/templates/ts my-app
+```
+
+
+```bash frame="none"
+deno -A npm:degit solidjs/templates/ts my-app
+```
+
+
+```bash frame="none"
+npm install
+```
+
+
+
+```bash frame="none"
+yarn install
+```
+
+
+
+```bash frame="none"
+pnpm install
+```
+
+
+
+```bash frame="none"
+bun install
+```
+
+
+```bash frame="none"
+deno install
+```
+
+
+```bash frame="none"
+npm run dev
+```
+
+
+
+```bash frame="none"
+yarn dev
+```
+
+
+
+```bash frame="none"
+pnpm dev
+```
+
+
+
+```bash frame="none"
+bun dev
+```
+
+
+```bash frame="none"
+deno task dev
+```
+
+-
+
- Your name is {user()?.name} +
-
+ Your email is
{user()?.email}+
+
{count()}
+
+// write signal by providing a value:
+setReady(true)
+
+// write signal by providing a function setter:
+const newCount = setCount((prev) => prev + 1)
+
+```
+
+{props.children}
+}
+```
+
+An important aspect of the `children` helper is that it forces the children to be created and resolved, as it accesses `props.children` immediately.
+This can be undesirable for conditional rendering, e.g., when using the children within a [`Error: {err.toString()}
}
+>
+ {item}
}
+{item}
}
+ #{index()} {item}
+
+ )}
+{item()}
}
+
+ #{index} {item()}
+
+ )}
+` unless the target is the document head.
+`useShadow` places the element in a Shadow Root for style isolation, and `isSVG` is required if inserting into an SVG element so that the `Loading...
}>
+ {(user) => ` is not inserted.
+
+```tsx
+
+
+```
+
+## Props
+
+| Name | Type | Default | Description |
+| :---------- | :-------- | :------------ | :------------------------------------------------ |
+| `mount` | `Node` | document.body | The DOM node to mount the portal in. |
+| `useShadow` | `boolean` | false | Whether to use a Shadow Root for style isolation. |
+| `isSVG` | `boolean` | false | Whether the mount node is an SVG element. |
+
+
+---
+title:
+order: 5
+---
+
+The `Show` control flow is used to conditionally render part of the view: it renders children when `when` is truthy, a fallback otherwise. It is similar to the ternary operator `(when ? children : fallback)` but is ideal for templating JSX.
+
+```ts
+import { Show } from "solid-js"
+import type { JSX } from "solid-js"
+
+function Show(props: {
+ when: T | undefined | null | false
+ keyed?: boolean
+ fallback?: JSX.Element
+ children: JSX.Element | ((item: T | Accessor) => JSX.Element)
+}): () => JSX.Element
+```
+
+Here's an example of using the `Show` control flow:
+
+```tsx
+ 0} fallback={
+```
+
+`Show` can also be used as a way of keying blocks to a specific data model. For example the function is re-executed whenever the user model is replaced.
+
+```tsx
+Loading...
} keyed>
+ {(user) => My Content
+Loading...
}>
+ My Content
+{user.firstName}
}
+
+```
+
+If the `keyed` property is not used, the argument of the child function will be an accessor containing the item.
+
+```tsx
+{user().firstName}
}
+{title()}
+{profile()?.name}
+ {profile()?.email}
+
+ )
+}
+
+```
+
+In this code, `profile()` starts as `undefined`, and when the fetcher code finishes, resolves to an object with `name` and `email` properties. Although the resource has not resolved yet, the two `div`s are already created and attached to the document body, albeit with empty text nodes. Once the resource resolves, the `div`s are updated with the appropriate data.
+
+The downside of this approach is that the user is shown an empty component - let's see if we can do better than that in this next snippet:
+
+```jsx
+const MyComponentWithShow = () => {
+ const [profile] = createResource(async () => {
+ /* fetcher code here */
+ })
+ return (
+ {profile().name}
+ {profile().email}
+ {profile()?.name}
+ {profile()?.email}
+ {profile().name}
+ {profile().email}
+ className was deprecated in Solid 1.4 in favor of{" "}
+ class.
+ console.log("Welcome!")} />
+```
+
+This directly attaches an event handler (via [`addEventListener`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener)) to the `div`.
+
+New in v1.9.0
+
+An aditional special syntax that allows full control of [`capture`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#capture), [`passive`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#passive), [`once`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#once) and [`signal`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#signal) is an intersection or combination of `EventListenerObject` & `AddEventListenerOptions`, as follows:
+
+```tsx
+const handler = {
+ handleEvent(e) {
+ console.log(e)
+ },
+ once:true,
+ passive:false,
+ capture:true
+}
+
+
+
+// or inline
+
+
+```
+
+This new syntax replaces the now deprecated `oncapture:` and it's future proof for any posible new event listener options.
+
+
+---
+title: on*
+order: 3
+---
+
+Event handlers in Solid typically take the form of `onclick` or `onClick` depending on style.
+
+```tsx
+
console.log(e.currentTarget)} />
+```
+
+Conceptually, this example attaches a `click` event listener (via [`addEventListener`](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener)) to the `div`. However, Solid actually handles common UI events that bubble and are composed (such as `click`) at the document level, and then synthetically implements delegation (capturing and bubbling). This improves performance for these common events by reducing the number of event handlers.
+
+Note that `onClick` handles the event `click`; in general, event names get mapped to lower case. If you need to work with event names containing capital letters, or use listener options such once, passive, capture see [`on:`](/reference/jsx-attributes/on) which attaches event handlers directly (also avoiding fancy delegation via document).
+
+Solid also supports passing a two-element array to the event handler to bind a value to the first argument of the event handler. This doesn't use `bind` or create an additional closure, so it is a highly optimized way of delegating events.
+
+```tsx
+function handler(itemId, e) {
+ /*...*/
+}
+
+
-
+
props.handleClick?.()} />
+```
+
+Note that `onChange` and `onInput` work according to their native behavior (unlike, say, React). [`onInput`](https://developer.mozilla.org/en-US/docs/Web/API/Element/input_event) will fire immediately after the value has changed; for most `` fields, [`onChange`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event) will only fire after the field loses focus. The event's `currentTarget` refers to the element that the event was attached to, while `target` gives the element that actually triggered the event (e.g. the user clicked on).
+
+
+---
+title: "@once"
+order: 5
+---
+
+Solid's compiler uses a heuristic for reactive wrapping and lazy evaluation of JSX expressions. Does it contain a function call, a property access, or JSX? If yes we wrap it in a getter when passed to components or in an effect if passed to native elements.
+
+Knowing this heuristic and its limitations, we can reduce overhead of things we know will never change by accessing them outside of the JSX. A lone variable will never be wrapped. We can also tell the compiler not to wrap them by starting the expression with a comment decorator `/* @once */`.
+
+```tsx
+{/*@once*/ state.wontUpdate}
+```
+
+
+---
+title: prop:*
+order: 6
+---
+
+Forces the prop to be treated as a property instead of an attribute.
+
+```tsx
+
+```
+
+
+ Type definitions are required when using TypeScript.
+ See the [TypeScript](/configuration/typescript#forcing-properties-and-custom-attributes) page for examples.
+
+
+---
+title: ref
+order: 7
+---
+
+Refs are a way of getting access to underlying DOM elements in our JSX. While it is true one could just assign an element to a variable, it is more optimal to leave components in the flow of JSX. Refs are assigned at render time but before the elements are connected to the DOM. They come in 2 flavors.
+
+```tsx
+// variable assigned directly by ref
+let myDiv;
+
+// use onMount or createEffect to read after connected to the DOM
+onMount(() => console.log(myDiv));
+
+
+
+// Or, callback function (called before connected to the DOM)
+
console.log(el)} />
+```
+
+Refs can also be used on Components. They still need to be attached on the other side.
+
+```tsx
+function MyComp(props) {
+ return
+}
+
+function App() {
+ let myDiv
+ onMount(() => console.log(myDiv.clientWidth))
+ return
+Directives only work with native HTML elements (HTML/SVG/MathML/Custom Elements).
+Directives are not forwarded and **won't work in user defined components**, such as `` [see also](https://github.com/solidjs/solid/discussions/722)
+
+
+
+---
+title: onCleanup
+order: 5
+---
+
+`onCleanup` registers a cleanup method that executes on disposal and recalculation of the current reactive scope.
+Can be used anywhere to clean up any side effects left behind by initialization.
+
+When used in a Component, it runs when the component is unmounted.
+When used in reactive contexts, such [`createEffect`](/reference/basic-reactivity/create-effect), [`createMemo`](/reference/basic-reactivity/create-memo) or a [`createRoot`](/reference/reactive-utilities/create-root), it runs when the reactive scope is disposed or refreshed.
+
+```ts
+import { onCleanup } from "solid-js"
+
+function onCleanup(fn: () => void): void;
+```
+
+Without the `onCleanup` function, the event listener would remain attached to the `document` even after the component is removed from the page.
+This can cause memory leaks and other issues.
+
+```tsx
+import { createSignal, onCleanup } from "solid-js"
+
+const Component = () => {
+ const [count, setCount] = createSignal(0);
+
+ const handleClick = () => setCount((value) => value + 1);
+
+ document.addEventListener("click", handleClick);
+
+ /**
+ * Remove the event listener when the component is removed/unmounted from the page.
+ */
+ onCleanup(() => {
+ document.removeEventListener("click", handleClick);
+ });
+
+ return Document has been clicked {count()} times ;
+};
+```
+
+
+---
+title: onMount
+order: 5
+---
+
+Registers a method that runs after initial rendering is done and the elements are mounted to the page.
+Ideal for using [refs](/reference/jsx-attributes/ref) and managing other one-time setup.
+
+```tsx
+import { onMount } from "solid-js"
+
+function onMount(fn: () => void): void
+
+```
+
+This is an alias for an effect that is non-tracking, meaning that it is equivalent to a [`createEffect`](/reference/basic-reactivity/create-effect) with no dependencies.
+
+```tsx
+// example that shows how to use onMount to get a reference to an element
+import { onMount } from "solid-js"
+
+function MyComponent() {
+ let ref: HTMLButtonElement
+
+ // when the component is mounted, the button will be disabled
+ onMount(() => {
+ ref.disabled = true
+ })
+ return
+}
+```
+
+
+---
+title: batch
+---
+
+```ts
+import { batch } from "solid-js"
+
+function batch(fn: () => T): T
+```
+
+`batch` is a low-level API that batches updates together.
+More precisely, `batch(fn)` holds the execution of downstream computations
+during the `fn` block, executing them all together once the block `fn` returns.
+Thus, instead of a downstream computation executing after every dependency
+update, it will update just once at the end of the batch.
+
+Batching improves performance by avoiding unnecessary recalculation.
+Suppose you have a downstream memo `down` that depends on
+multiple upstream signals `up1`, `up2`, and `up3`:
+
+```ts
+import { createSignal, createMemo, createEffect } from "solid-js"
+const [up1, setUp1] = createSignal(1)
+const [up2, setUp2] = createSignal(2)
+const [up3, setUp3] = createSignal(3)
+const down = createMemo(() => up1() + up2() + up3())
+// For illustration, monitor when `down` gets recomputed:
+createEffect(() => console.log(down())) // outputs 6
+```
+
+If you directly update all of the upstream signals outside of batch mode,
+then `down` will recompute every time.
+
+```ts
+setUp1(4) // recomputes down, outputs 9
+setUp2(5) // recomputes down, outputs 12
+setUp3(6) // recomputes down, outputs 15
+```
+
+If instead you update the upstream signals within a `batch`, then `down`
+will update only once at the end:
+
+```ts
+batch(() => {
+ setUp1(10) // doesn't update down yet
+ setUp2(10) // doesn't update down yet
+ setUp3(10) // doesn't update down yet
+}) // recomputes down, outputs 30
+```
+
+The impact is even more dramatic if you have *m* downstream computations
+(memos, effects, etc.) that each depend on *n* upstream signals.
+Without batching, modifying all *n* upstream signals
+would cause *m n* updates to the downstream computations.
+With batching, modifying all *n* upstream signals
+would cause *m* updates to the downstream computations.
+Given that each update takes at least *n* time
+(just to read the upstream signals), this cost savings can be significant.
+Batching is also especially helpful when the downstream effects include
+DOM updates, which can be expensive.
+
+Solid uses `batch` internally to automatically batch updates for you
+in a few cases:
+
+* Within [`createEffect`](/reference/basic-reactivity/create-effect)
+ and [`onMount`](/reference/lifecycle/on-mount)
+ (unless they are outside a [root](/reference/reactive-utilities/create-root))
+* Within the [setter of a store](/reference/store-utilities/create-store#setter)
+ (which can update several properties at once)
+* Within array methods (e.g. `Array.prototype.splice`) of a
+ [mutable store](/reference/store-utilities/create-mutable)
+ (which can update several elements at once)
+
+These save you from having to use `batch` yourself in many cases.
+For the most part, automatic batching should be transparent to you,
+because accessing a signal or memo will cause it to update if it is out of date
+(as of Solid 1.4). For example:
+
+```ts
+batch(() => {
+ setUp1(11) // doesn't update down yet
+ setUp2(11) // doesn't update down yet
+ setUp3(11) // doesn't update down yet
+ console.log(down()) // recomputes down, outputs 33
+ setUp1(12) // doesn't update down yet
+ setUp2(12) // doesn't update down yet
+ setUp3(12) // doesn't update down yet
+}) // recomputes down, outputs 36
+```
+
+You can think of `batch(fn)` as setting a global "batch mode" variable,
+calling the function `fn`, and then restoring the global variable to its
+previous value.
+This means that you can nest `batch` calls, and they will form one big batch.
+It also means that, if `fn` is asynchronous,
+only the updates before the first `await` will be batched.
+
+
+---
+title: catchError
+---
+
+
+New in v1.7.0
+
+
+```tsx
+import { catchError } from "solid-js"
+
+function catchError(tryFn: () => T, onError: (err: any) => void): T
+```
+
+Wraps a `tryFn` with an error handler that fires if an error occurs below that point.
+Only the nearest scope error handlers execute.
+Rethrow to trigger up the line.
+
+---
+title: createRoot
+---
+
+```ts
+import { createRoot } from "solid-js"
+
+function createRoot(fn: (dispose: () => void) => T): T
+
+```
+
+Creates a new non-tracked owner scope that doesn't auto-dispose.
+This is useful for nested reactive scopes that you do not wish to release when the parent re-evaluates.
+
+All Solid code should be wrapped in one of these top level as they ensure that all memory/computations are freed up.
+Normally you do not need to worry about this as createRoot is embedded into all render entry functions.
+
+
+---
+title: from
+---
+
+```tsx
+import { from } from "solid-js"
+
+function from(
+ producer:
+ | ((setter: (v: T) => T) => () => void)
+ | {
+ subscribe: (
+ fn: (v: T) => void
+ ) => (() => void) | { unsubscribe: () => void }
+ }
+): () => T | undefined
+
+```
+
+A helper to make it easier to interop with external producers like RxJS observables or with Svelte Stores.
+This basically turns any subscribable (object with a subscribe method) into a Signal and manages subscription and disposal.
+
+```tsx
+const signal = from(obsv$)
+```
+
+It can also take a custom producer function where the function is passed a setter function that returns an unsubscribe function:
+
+```tsx
+const clock = from((set) => {
+ const interval = setInterval(() => {
+ set((v) => v + 1)
+ }, 1000)
+
+ return () => clearInterval(interval)
+})
+```
+
+## Arguments
+
+| Name | Type | Description |
+| :------- | :----------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------- |
+| producer | `((setter: (v: T) => T) => () => void) \| { subscribe: (fn: (v: T) => void) => (() => void) \| { unsubscribe: () => void }; }` | The producer function or subscribable object |
+
+
+---
+title: getOwner
+---
+
+```tsx
+import { getOwner } from "solid-js"
+import type { Owner } from "solid-js"
+
+function getOwner(): Owner
+
+```
+
+Gets the reactive scope that owns the currently running code, e.g., for passing into a later call to `runWithOwner` outside of the current scope.
+
+Internally, computations (effects, memos, etc.) create owners which are children of their owner, all the way up to the root owner created by `createRoot` or `render`.
+In particular, this ownership tree lets Solid automatically clean up a disposed computation by traversing its subtree and calling all `onCleanup` callbacks.
+For example, when a createEffect's dependencies change, the effect calls all descendant `onCleanup` callbacks before running the effect function again.
+Calling `getOwner` returns the current owner node that is responsible for disposal of the current execution block.
+
+Components are not computations, so do not create an owner node, but they are typically rendered from a `createEffect` which does, so the result is similar: when a component gets unmounted, all descendant `onCleanup` callbacks get called.
+Calling `getOwner` from a component scope returns the owner that is responsible for rendering and unmounting that component.
+
+Note that the owning reactive scope isn't necessarily tracking.
+For example, untrack turns off tracking for the duration of a function (without creating a new reactive scope), as do components created via JSX (``).
+
+
+---
+title: indexArray
+---
+
+```tsx
+import { indexArray } from "solid-js"
+
+function indexArray(
+ list: () => readonly T[],
+ mapFn: (v: () => T, i: number) => U
+): () => U[]
+
+```
+
+Similar to `mapArray` except it maps by index.
+The item is a signal and the index is now the constant.
+
+Underlying helper for the `` control flow.
+
+```tsx
+const mapped = indexArray(source, (model) => {
+ return {
+ get id() {
+ return model().id
+ }
+ get firstInitial() {
+ return model().firstName[0];
+ },
+ get fullName() {
+ return `${model().firstName} ${model().lastName}`;
+ },
+ }
+});
+```
+
+## Arguments
+
+| Name | Type | Description |
+| :---- | :----------------------------- | :-------------------- |
+| list | `() => readonly T[]` | The list to map. |
+| mapFn | `(v: () => T, i: number) => U` | The mapping function. |
+
+
+---
+title: mapArray
+---
+
+```ts
+import { mapArray } from "solid-js"
+
+function mapArray(
+ list: () => readonly T[],
+ mapFn: (v: T, i: () => number) => U
+): () => U[]
+
+```
+
+Reactive map helper that caches each item by reference to reduce unnecessary mapping on updates.
+It only runs the mapping function once per value and then moves or removes it as needed.
+The index argument is a signal. The map function itself is not tracking.
+
+Underlying helper for the `` control flow.
+
+```ts
+const mapped = mapArray(source, (model) => {
+ const [name, setName] = createSignal(model.name)
+ const [description, setDescription] = createSignal(model.description)
+
+ return {
+ id: model.id,
+ get name() {
+ return name()
+ },
+ get description() {
+ return description()
+ },
+ setName,
+ setDescription,
+ }
+})
+```
+
+## Arguments
+
+| Name | Type | Description |
+| :---- | :----------------------------- | :----------------------- |
+| list | `() => readonly T[]` | The source array to map. |
+| mapFn | `(v: T, i: () => number) => U` | The mapping function. |
+
+
+---
+title: mergeProps
+---
+
+```ts
+import { mergeProps } from "solid-js"
+
+function mergeProps(...sources: any): any
+
+```
+
+A reactive object **merge** method.
+Useful for setting default props for components in case caller doesn't provide them.
+Or cloning the props object including reactive properties.
+
+This method works by using a proxy and resolving properties in reverse order.
+This allows for dynamic tracking of properties that aren't present when the prop object is first merged.
+
+```ts
+// default props
+props = mergeProps({ name: "Smith" }, props)
+
+// clone props
+newProps = mergeProps(props)
+
+// merge props
+props = mergeProps(props, otherProps)
+```
+
+
+---
+title: observable
+---
+
+```ts
+import { observable } from "solid-js"
+
+function observable(input: () => T): Observable
+
+```
+
+This method takes a signal and produces an Observable.
+You can consume it from another Observable library of your choice, typically with the `from` operator.
+
+```ts
+// How to integrate rxjs with a Solid signal
+import { observable } from "solid-js"
+import { from } from "rxjs"
+
+const [s, set] = createSignal(0)
+
+const obsv$ = from(observable(s))
+
+obsv$.subscribe((v) => console.log(v))
+```
+
+You can also use `from` without rxjs; check out this [page](/reference/reactive-utilities/from).
+
+
+---
+title: on
+---
+
+```ts
+import { on } from "solid-js"
+
+function on any> | (() => any), U>(
+ deps: T,
+ fn: (input: T, prevInput: T, prevValue?: U) => U,
+ options: { defer?: boolean } = {}
+): (prevValue?: U) => U | undefined
+```
+
+`on` is designed to be passed into a computation to make its dependencies explicit.
+If an array of dependencies is passed, `input` and `prevInput` are arrays.
+
+```ts
+createEffect(on(a, (v) => console.log(v, b())));
+
+// is equivalent to:
+createEffect(() => {
+ const v = a();
+ untrack(() => console.log(v, b()));
+});
+```
+
+You can also not run the computation immediately and instead opt in for it to only run on change by setting the defer option to true.
+
+```ts
+// doesn't run immediately
+createEffect(on(a, (v) => console.log(v), { defer: true }));
+
+setA("new"); // now it runs
+```
+
+## Using `on` with stores
+
+
+ Please note that on stores and mutable, adding or removing a property from the
+ parent object will trigger an effect. See [`createMutable`](/reference/store-utilities/create-mutable)
+
+
+
+```ts
+const [state, setState] = createStore({ a: 1, b: 2 });
+
+// this will not work
+createEffect(on(state.a, (v) => console.log(v)));
+
+setState({ a: 3 }); // logs nothing
+
+// instead, use an arrow function
+createEffect(
+ on(
+ () => state.a,
+ (v) => console.log(v)
+ )
+);
+
+setState({ a: 4 }); // logs 4
+```
+
+## Arguments and options
+
+| Argument | Type | Description |
+| :------- | :--------------------------------------------- | :------------------------------------------------ |
+| deps | `T` | The dependencies to watch. |
+| fn | `(input: T, prevInput: T, prevValue?: U) => U` | The function to run when the dependencies change. |
+| options | `{ defer?: boolean }` | Options to configure the effect. |
+
+
+---
+title: runWithOwner
+order: 5
+---
+
+```ts
+import { runWithOwner } from "solid-js"
+import type { Owner } from "solid-js"
+
+function runWithOwner(owner: Owner, fn: (() => void) => T): T
+```
+
+Executes the given function under the provided owner, instead of (and without affecting) the owner of the outer scope.
+By default, computations created by `createEffect`, `createMemo`, etc. are owned by the owner of the currently executing code (the return value of `getOwner`), so in particular these will get disposed when their owner does.
+Calling `runWithOwner` provides a way to override this default to a manually specified owner (typically, the return value from a previous call to `getOwner`), enabling more precise control of when computations get disposed.
+
+Having a (correct) owner is important for two reasons:
+
+- Computations without an owner cannot be cleaned up.
+For example, if you call `createEffect` without an owner (e.g., in the global scope), the effect will continue running forever, instead of being disposed when its owner gets disposed.
+
+- `useContext` obtains context by walking up the owner tree to find the nearest ancestor providing the desired context.
+So without an owner you cannot look up any provided context (and with the wrong owner, you might obtain the wrong context).
+
+Manually setting the owner is especially helpful when doing reactivity outside of any owner scope.
+In particular, asynchronous computation (via either `async` functions or callbacks like `setTimeout`) lose their automatically set owner, so remembering the original owner via `getOwner` and restoring it via `runWithOwner` is necessary in these cases.
+For example:
+
+```ts
+const owner = getOwner()
+setTimeout(() => {
+ // This callback gets run without owner.
+ // Restore owner via runWithOwner:
+ runWithOwner(owner, () => {
+ const foo = useContext(FooContext)
+ createEffect(() => {
+ console.log(foo)
+ })
+ })
+}, 1000)
+```
+
+**Note:** that owners are not what determines dependency tracking, so `runWithOwner` does not help with tracking in asynchronous functions; use of reactive state in the asynchronous part (e.g. after the first `await`) will not be tracked as a dependency.
+
+
+---
+title: splitProps
+---
+
+```ts
+import { splitProps } from "solid-js"
+
+function splitProps(
+ props: T,
+ ...keys: Array<(keyof T)[]>
+): [...parts: Partial]
+
+```
+
+Splits a reactive object by keys.
+
+It takes a reactive object and any number of arrays of keys; for each array of keys, it will return a reactive object with just those properties of the original object.
+The last reactive object in the returned array will have any leftover properties of the original object.
+
+This can be useful if you want to consume a subset of props and pass the rest to a child.
+
+```tsx
+function MyComponent(props) {
+ const [local, others] = splitProps(props, ["children"])
+
+ return (
+ <>
+
+
+```
+
+Similar to `useTransition` except there is no associated pending state.
+This one can just be used directly to start the Transition.
+
+
+---
+title: untrack
+---
+
+Ignores tracking any of the dependencies in the executing code block and returns the value. This helper is useful when a certain `prop` will never update and thus it is ok to use it outside of the reactive context.
+
+```tsx title="component.tsx"
+import { untrack } from "solid-js"
+
+export function Component(props) {
+ const value = untrack(() => props.value)
+
+ return
+
+
+---
+title: useTransition
+---
+
+```ts
+import { useTransition } from "solid-js"
+
+function useTransition(): [
+ pending: () => boolean,
+ startTransition: (fn: () => void) => Promise
+]
+
+```
+
+Used to batch async updates in a transaction deferring commit until all async processes are complete.
+This is tied into Suspense and only tracks resources read under Suspense boundaries.
+
+```ts
+const [isPending, start] = useTransition();
+
+// check if transitioning
+isPending();
+
+// wrap in transition
+start(() => setSignal(newValue), () => /* transition is done */)
+```
+
+
+---
+title: DEV
+---
+
+```ts
+import { DEV } from "solid-js"
+
+const DEV: object | undefined
+```
+
+On the client, Solid provides (via [conditional exports](https://nodejs.org/api/packages.html#conditional-exports)) different builds depending on whether the **development** condition is set.
+Development mode provides some additional checking — e.g. detecting accidental use of multiple instances of Solid — which are removed in production builds.
+
+If you want code to run only in development mode (most useful in libraries), you can check whether the **DEV** export is defined.
+Note that it is always defined on the server, so you may want to combine with [isServer](/reference/rendering/is-server):
+
+```ts
+import { DEV } from "solid-js"
+import { isServer } from "solid-js/web"
+
+if (DEV && !isServer) {
+ console.log(...);
+}
+```
+
+
+---
+title: hydrate
+---
+
+```ts
+import { hydrate } from "solid-js/web"
+import type { JSX } from "solid-js"
+import type { MountableElement } from "solid-js/web"
+
+function hydrate(
+ fn: () => JSX.Element,
+ node: MountableElement,
+ options?: { renderId?: string; owner?: unknown }
+): () => void
+
+```
+
+This method is similar to `render` except that it attempts to rehydrate what is already rendered to the DOM.
+When initializing in the browser a page has already been server rendered.
+
+```ts
+const dispose = hydrate(App, document.getElementById("app"))
+```
+
+## Parameters
+
+| Prop | type | description |
+| -------------------- | ------------------ | ----------------------------------------------- |
+| fn | `() => JSX.Element`| Function that returns the application code. |
+| node | MountableElement | DOM Element to mount the application to |
+| options.renderId | string | |
+| options.owner | unknown | |
+
+---
+title: hydrationScript
+---
+
+```ts
+import { generateHydrationScript, HydrationScript } from "solid-js/web"
+import type { JSX } from "solid-js"
+
+function generateHydrationScript(options: {
+ nonce?: string
+ eventNames?: string[]
+}): string
+
+function HydrationScript(props: {
+ nonce?: string
+ eventNames?: string[]
+}): JSX.Element
+
+```
+
+Hydration Script is a special script that should be placed once on the page to bootstrap hydration before Solid's runtime has loaded.
+It comes both as a function that can be called and inserted in an HTML string, or as a Component if you are rendering JSX from the `` tag.
+
+The options are for the **nonce** to be put on the script tag and any event names for that Solid should capture before scripts have loaded and replay during hydration.
+These events are limited to those that Solid delegates which include most UI Events that are composed and bubble.
+By default it is only click and input events.
+
+
+---
+title: isServer
+---
+
+```ts
+import { isServer } from "solid-js/web"
+
+const isServer: boolean
+
+```
+
+This indicates that the code is being run as the server or browser bundle.
+As the underlying runtimes export this as a constant boolean it allows bundlers to eliminate the code and their used imports from the respective bundles.
+
+```ts
+import { isServer } from "solid-js/web";
+
+if (isServer) {
+ // I will never make it to the browser bundle
+} else {
+ // won't be run on the server;
+}
+```
+
+
+---
+title: renderToStream
+---
+
+```ts
+import { renderToStream } from "solid-js/web"
+
+function renderToStream(
+ fn: () => T,
+ options?: {
+ nonce?: string
+ renderId?: string
+ onCompleteShell?: () => void
+ onCompleteAll?: () => void
+ }
+): {
+ pipe: (writable: { write: (v: string) => void }) => void
+ pipeTo: (writable: WritableStream) => void
+}
+
+```
+
+This method renders to a stream.
+It renders the content synchronously including any Suspense fallback placeholders, and then continues to stream the data and HTML from any async resource as it completes.
+
+```ts
+// node
+renderToStream(App).pipe(res)
+
+// web stream
+const { readable, writable } = new TransformStream()
+renderToStream(App).pipeTo(writable)
+```
+
+`onCompleteShell` fires when synchronous rendering is complete before writing the first flush to the stream out to the browser.
+`onCompleteAll` is called when all server Suspense boundaries have settled.
+`renderId` is used to namespace renders when having multiple top level roots.
+
+
+ This API replaces the previous pipeToWritable and pipeToNodeWritable
+ APIs.
+
+
+## Options
+
+| Name | Type | Description |
+| --------------- | ---------- | ---------------------------------------------------------------- |
+| nonce | string | The nonce to use for inline scripts. |
+| renderId | string | The id to use for this render. |
+| onCompleteShell | () => void | A callback that fires when the shell is complete. |
+| onCompleteAll | () => void | A callback that fires when all Suspense boundaries have settled. |
+
+
+---
+title: renderToStringAsync
+---
+
+```ts
+import { renderToStringAsync } from "solid-js/web"
+
+function renderToStringAsync(
+ fn: () => T,
+ options?: {
+ timeoutMs?: number
+ renderId?: string
+ nonce?: string
+ }
+): Promise
+
+```
+
+Same as `renderToString` except that it will wait for all `` boundaries to resolve before returning the results.
+Resource data is automatically serialized into the script tag and will be hydrated on client load.
+
+`renderId` is used to namespace renders when having multiple top level roots.
+
+```ts
+const html = await renderToStringAsync(App)
+```
+
+## Options
+
+| Name | Type | Description |
+| ----------- | -------- | -------------------------------------------------------------------------------------------- |
+| `timeoutMs` | `number` | The number of milliseconds to wait for a `` boundary to resolve before timing out. |
+| `renderId` | `string` | The id to use for the render. |
+| `nonce` | `string` | The nonce to use for the script tag. |
+
+
+---
+title: renderToString
+---
+
+```ts
+import { renderToString } from "solid-js/web"
+
+function renderToString(
+ fn: () => T,
+ options?: {
+ nonce?: string
+ renderId?: string
+ }
+): string
+
+```
+
+Renders to a string synchronously.
+The function also generates a script tag for progressive hydration.
+Options include eventNames to listen to before the page loads and play back on hydration, and nonce to put on the script tag.
+
+`renderId` is used to namespace renders when having multiple top level roots.
+
+```ts
+const html = renderToString(App)
+```
+
+## Options
+
+| Name | Type | Description |
+| ---------- | -------- | ------------------------------------ |
+| `nonce` | `string` | The nonce to use for the script tag. |
+| `renderId` | `string` | The id to use for the script tag. |
+
+
+---
+title: render
+---
+
+```ts
+import { render } from "solid-js/web"
+import type { JSX } from "solid-js"
+import type { MountableElement } from "solid-js/web"
+
+function render(
+ code: () => JSX.Element,
+ element: MountableElement
+): () => void
+
+```
+
+This is the browser app entry point.
+Provide a top-level component function and an element to mount to.
+It is recommended this element be empty: while `render` will just append children, the returned dispose function will remove all children.
+
+```ts
+const dispose = render(App, document.getElementById("app"))
+// or
+const dispose = render(() => (fn: (v: T) => T, value?: T): void
+
+```
+
+`createComputed` creates a new computation that immediately runs the given function in a tracking scope, thus automatically tracking its dependencies, and automatically reruns the function whenever the dependencies changes.
+The function gets called with an argument equal to the value returned from the function's last execution, or on the first call, equal to the optional second argument to `createComputed`.
+Note that the return value of the function is not otherwise exposed; in particular, createComputed has no return value.
+
+`createComputed` is the most immediate form of reactivity in Solid, and is most useful for building other reactive primitives.
+For example, some other Solid primitives are built from `createComputed`.
+However, it should be used with care, as `createComputed` can easily cause more unnecessary updates than other reactive primitives.
+Before using it, consider the closely related primitives [`createMemo`](/reference/basic-reactivity/create-memo) and [`createRenderEffect`](/reference/secondary-primitives/create-render-effect).
+
+Like `createMemo`, `createComputed` calls its function immediately on updates (unless you're in a [batch](/reference/reactive-utilities/batch), [effect](/reference/basic-reactivity/create-effect), or [transition](/reference/reactive-utilities/use-transition)).
+However, while `createMemo` functions should be pure (not set any signals), `createComputed` functions can set signals.
+Related, `createMemo` offers a readonly signal for the return value of the function, whereas to do the same with `createComputed` you would need to set a signal within the function.
+If it is possible to use pure functions and `createMemo`, this is likely more efficient, as Solid optimizes the execution order of memo updates, whereas updating a signal within `createComputed` will immediately trigger reactive updates some of which may turn out to be unnecessary.
+
+## Arguments
+
+| Name | Type | Description |
+| :------ | :------------ | :----------------------------------------- |
+| `fn` | `(v: T) => T` | The function to run in a tracking scope. |
+| `value` | `T` | The initial value to pass to the function. |
+
+
+---
+title: createDeferred
+---
+
+```ts
+import { createDeferred } from "solid-js"
+
+function createDeferred(
+ source: () => T,
+ options?: {
+ timeoutMs?: number
+ equals?: false | ((prev: T, next: T) => boolean)
+ name?: string
+ }
+): () => T
+
+```
+
+Creates a readonly that only notifies downstream changes when the browser is idle.
+`timeoutMs` is the maximum time to wait before forcing the update.
+
+## Options
+
+| Name | Type | Description |
+| --------- | ------------------------------------------ | ------------------------------------------------------ |
+| timeoutMs | `number` | The maximum time to wait before forcing the update. |
+| equals | `false or ((prev: T, next: T) => boolean)` | A function that returns true if the value has changed. |
+| name | `string` | The name of the readonly. |
+
+
+
+---
+title: createReaction
+---
+
+```ts
+import { createReaction } from "solid-js"
+
+function createReaction(onInvalidate: () => void): (fn: () => void) => void
+
+```
+
+Sometimes it is useful to separate tracking from re-execution.
+This primitive registers a side effect that is run the first time the expression wrapped by the returned tracking function is notified of a change.
+
+```ts
+const [s, set] = createSignal("start")
+
+const track = createReaction(() => console.log("something"))
+
+// run the reaction next time `s` changes.
+track(() => s())
+
+set("end") // "something"
+
+set("final") // no-op since the reaction only runs on the first update, need to call `track` again.
+```
+
+
+---
+title: createRenderEffect
+---
+
+```ts
+import { createRenderEffect } from "solid-js"
+
+function createRenderEffect(fn: (v: T) => T, value?: T): void
+
+```
+
+A render effect is a computation similar to a regular effect (as created by [`createEffect`](/reference/basic-reactivity/create-effect)), but differs in when Solid schedules the first execution of the effect function.
+While `createEffect` waits for the current rendering phase to be complete, `createRenderEffect` immediately calls the function.
+Thus the effect runs as DOM elements are being created and updated, but possibly before specific elements of interest have been created, and probably before those elements have been connected to the document.
+In particular, **refs** will not be set before the initial effect call.
+Indeed, Solid uses `createRenderEffect` to implement the rendering phase itself, including setting of **refs**.
+
+Reactive updates to render effects are identical to effects: they queue up in response to a reactive change (e.g., a single signal update, or a batch of changes, or collective changes during an entire render phase) and run in a single [`batch`](/reference/reactive-utilities/batch) afterward (together with effects).
+In particular, all signal updates within a render effect are batched.
+
+Here is an example of the behavior. (Compare with the example in [`createEffect`](/reference/basic-reactivity/create-effect).)
+
+```ts
+// assume this code is in a component function, so is part of a rendering phase
+const [count, setCount] = createSignal(0)
+
+// this effect prints count at the beginning and when it changes
+createRenderEffect(() => console.log("count =", count()))
+// render effect runs immediately, printing `count = 0`
+console.log("hello")
+setCount(1) // effect won't run yet
+setCount(2) // effect won't run yet
+
+queueMicrotask(() => {
+ // now `count = 2` will print
+ console.log("microtask")
+ setCount(3) // immediately prints `count = 3`
+ console.log("goodbye")
+})
+
+// --- overall output: ---
+// count = 0 [this is the only added line compared to createEffect]
+// hello
+// count = 2
+// microtask
+// count = 3
+// goodbye
+```
+
+Just like `createEffect`, the effect function gets called with an argument equal to the value returned from the effect function's last execution, or on the first call, equal to the optional second argument of `createRenderEffect`.
+
+## Arguments
+
+| Name | Type | Description |
+| :------ | :------------ | :----------------------------------------------------- |
+| `fn` | `(v: T) => T` | The effect function to be called. |
+| `value` | `T` | The initial value to be passed to the effect function. |
+
+
+---
+title: createSelector
+---
+
+```ts
+import { createSelector } from "solid-js"
+
+function createSelector(
+ source: () => T,
+ fn?: (a: U, b: T) => boolean
+): (key: U) => boolean
+```
+
+Creates a parameterized derived boolean signal `selector(key)` that indicates
+whether `key` is equal to the current value of the `source` signal.
+These signals are optimized to notify each subscriber only when their `key`
+starts or stops matching the reactive `source` value
+(instead of every time `key` changes).
+If you have *n* different subscribers with different keys,
+and the `source` value changes from `a` to `b`, then
+instead of all *n* subscribers updating,
+at most two subscribers will update:
+the signal with key `a` will change to `false`,
+and the signal with key `b` will change to `true`.
+Thus it reduces from *n* updates to 2 updates.
+
+Useful for defining the selection state of several selectable elements.
+For example:
+
+```tsx
+const [selectedId, setSelectedId] = createSignal()
+const isSelected = createSelector(selectedId)
+
+
+ {(item) => {item.name} }
+
+```
+
+In the code above, each `li` element receives an `active` class
+exactly when the corresponding `item.id` is equal to `selectedId()`.
+When the `selectedId` signal changes, the `li` element(s) that previously
+had previously matching `id` get the `active` class removed, and the
+`li` element(s) that now have a matching `id` get the `active` class added.
+All other `li` elements get skipped, so if `id`s are distinct,
+only 2 DOM operations get performed.
+
+By contrast, the following code would perform `list().length` DOM operations
+every time the `selectedId` signal changes:
+
+```tsx
+const [selectedId, setSelectedId] = createSignal()
+
+
+ {(item) => {item.name} }
+
+```
+
+## Arguments
+
+| Name | Type | Description |
+| :------- | :------------------------ | :------------------------------------------- |
+| `source` | `() => T` | The source signal to get the value from and compare with keys. |
+| `fn` | `(a: U, b: T) => boolean` | A function to compare the key and the value, returning whether they should be treated as equal. Default: `===` |
+
+
+---
+title: getRequestEvent
+---
+
+Solid uses Async Local Storage as a way of injecting the request context anywhere on the server.
+The server provides a utility function to access this context
+(called a `RequestEvent`).
+
+```js
+import { getRequestEvent } from "solid-js/web"
+import type { RequestEvent } from "solid-js/web"
+
+function getRequestEvent(): RequestEvent | undefined
+```
+
+You can retrieve the request event by calling `getRequestEvent`:
+
+```js
+import { getRequestEvent } from "solid-js/web"
+
+const event = getRequestEvent()
+```
+
+## Request
+
+`.request` is the most important property of the `RequestEvent`.
+This is a Web [Request object](https://developer.mozilla.org/en-US/docs/Web/API/Request) that represents the current request to the server.
+You can access properties off of it such as `url` and `headers`.
+ `body`, however, does not typically need to be handled directly for things such as server functions or rendering, which already handle mapping.
+
+```js
+import { getRequestEvent } from "solid-js/web"
+
+const event = getRequestEvent();
+if (event) {
+ const auth = event.request.headers.get("Authorization");
+}
+```
+
+## Response
+
+The `getRequestEvent` can also be used to stub out the Response - this extends the [options that can be passed to the `Response constructor`](https://developer.mozilla.org/en-US/docs/Web/API/Response/Response#options).
+This is kept up to date so it can be used to read and write headers and status for the current response.
+
+```js
+import { getRequestEvent } from "solid-js/web"
+
+const event = getRequestEvent();
+if (event) {
+ event.response.headers.append("Set-Cookie", "foo=hello");
+ event.response.status = 201;
+}
+```
+
+### Change event.response or create a new Response
+
+The `getRequestEvent` event is considered global and lasts the life of the request.
+Therefore, if you are calling a server function on the server during SSR or an RPC call, setting values on `event.response` will reflect on that request.
+
+The returned response will only impact the response when it is an RPC call.
+This is important because some headers previously set may not be needed to be set for the whole page, but only for a specific request.
+
+**Note:** This is important to keep in mind when choosing where to set headers and responses.
+
+
+ See this guide on [Request
+ Events](/solid-start/advanced/request-events).
+
+
+
+---
+title: createMutable
+---
+
+`createMutable` creates a new mutable Store proxy object that provides a way to selectively trigger updates only when values change.
+
+By intercepting property access, it allows automatic tracking of deep nesting via proxy making it useful for integrating external systems or serving as a compatibility layer with frameworks like MobX or Vue.
+
+```tsx
+import { createMutable } from "solid-js/store"
+import type { Store, StoreNode } from "solid-js/store"
+
+function createMutable(state: T | Store): Store;
+```
+
+
+ It's important to recognize that a mutable state, which can be passed around and modified anywhere, may complicate the code structure and increase the risk of breaking unidirectional flow.
+
+ For a more robust alternative, it is generally recommended to use `createStore` instead.
+ Additionally, the [`produce`](/reference/store-utilities/produce) utility can provide many of these same benefits without the associated downsides.
+
+
+```tsx
+import { createMutable } from "solid-js/store"
+
+const state = createMutable({
+ someValue: 0,
+ list: [],
+});
+
+// read value
+state.someValue;
+
+// set value
+state.someValue = 5;
+
+state.list.push(anotherValue);
+```
+
+Mutables support setters along with getters.
+
+```tsx
+const user = createMutable({
+ firstName: "John",
+ lastName: "Smith",
+ get fullName() {
+ return `${this.firstName} ${this.lastName}`;
+ },
+ set setFullName(value) {
+ [this.firstName, this.lastName] = value.split(" ");
+ },
+});
+```
+
+
+
+---
+title: createStore
+---
+
+Stores were intentionally designed to manage data structures like objects and arrays but are capable of handling other data types, such as strings and numbers.
+
+## Types Signature
+
+```tsx
+import { createStore } from "solid-js/store"
+import type { StoreNode, Store, SetStoreFunction } from "solid-js/store"
+
+function createStore(
+ state: T | Store
+): [get: Store, set: SetStoreFunction];
+
+type Store = T; // conceptually readonly, but not typed as such
+```
+
+## Usage
+
+```tsx
+import { createStore } from "solid-js/store";
+
+// Initialize store
+const [store, setStore] = createStore({
+ userCount: 3,
+ users: [
+ {
+ id: 0,
+ username: "felix909",
+ location: "England",
+ loggedIn: false,
+ },
+ {
+ id: 1,
+ username: "tracy634",
+ location: "Canada",
+ loggedIn: true,
+ },
+ {
+ id: 1,
+ username: "johny123",
+ location: "India",
+ loggedIn: true,
+ },
+ ],
+});
+```
+
+## Getter
+
+Store objects support the use of getters to store derived values.
+
+```tsx
+const [state, setState] = createStore({
+ user: {
+ firstName: "John",
+ lastName: "Smith",
+ get fullName() {
+ return `${this.firstName} ${this.lastName}`;
+ },
+ },
+});
+```
+
+## Setter
+
+Changes can take the form of function that passes previous state and returns new state or a value.
+Objects are always shallowly merged. Set values to undefined to delete them from the Store.
+In TypeScript, you can delete a value by using a non-null assertion, like `undefined!`.
+
+```tsx
+const [state, setState] = createStore({
+ firstName: "John",
+ lastName: "Miller",
+});
+
+setState({ firstName: "Johnny", middleName: "Lee" });
+// ({ firstName: 'Johnny', middleName: 'Lee', lastName: 'Miller' })
+
+setState((state) => ({ preferredName: state.firstName, lastName: "Milner" }));
+// ({ firstName: 'Johnny', preferredName: 'Johnny', middleName: 'Lee', lastName: 'Milner' })
+```
+
+---
+
+To learn more about using stores check the [Stores Guide](/concepts/stores), and the **Store utilities** section for more advanced APIs.
+
+
+---
+title: modifyMutable
+---
+
+`modifyMutable` streamlines the process of making multiple changes to a mutable Store, as obtained through the use of [`createMutable`](/reference/store-utilities/create-mutable).
+
+It operates within a single [`batch`](/reference/reactive-utilities/batch), ensuring that dependent computations are updated just once, rather than triggering updates for each individual change.
+
+```tsx
+import { modifyMutable } from "solid-js/store"
+
+function modifyMutable(mutable: T, modifier: (state: T) => T): void
+```
+
+The function takes two arguments:
+
+1. The first argument is the mutable Store that needs modification.
+2. The second argument is a Store modifier, which could be one of those returned by [`reconcile`](/reference/store-utilities/reconcile).
+
+
+ When passing in your own modifier function, it's important to be aware that
+ its argument is an unwrapped version of the store.
+
+
+For example, if the UI depends on multiple fields of a mutable:
+
+```tsx
+import { createMutable } from "solid-js/store"
+
+const state = createMutable({
+ user: {
+ firstName: "John",
+ lastName: "Smith",
+ },
+});
+
+(
+ fn: (state: T) => void
+): (
+ state: T extends NotWrappable ? T : Store
+) => T extends NotWrappable ? T : Store;
+```
+
+For use with `createStore`:
+
+```tsx
+import { produce } from "solid-js/store";
+
+const [state, setState] = createStore({
+ user: {
+ name: "John",
+ age: 30,
+ },
+ list: ["book", "pen"],
+});
+
+setState(
+ produce((state) => {
+ state.user.name = "Jane";
+ state.list.push("pencil");
+ })
+);
+```
+
+
+---
+title: reconcile
+---
+
+`reconcile` is designed for diffing data changes in situations where granular updates cannot be applied.
+This is useful when dealing with immutable data from stores or handling large API responses.
+
+```tsx
+import { reconcile } from "solid-js/store"
+import type { NotWrappable, Store } from "solid-js/store"
+
+function reconcile(
+ value: T | Store,
+ options?: {
+ key?: string | null;
+ merge?: boolean;
+ } = { key: "id" }
+): (
+ state: T extends NotWrappable ? T : Store
+) => T extends NotWrappable ? T : Store
+```
+
+`reconcile` has a `key` option that can be used when available to match items.
+The `value` accepts either a value of type `T` or a Store containing values of type `T`.
+This represents the data to be reconciled.
+
+The `reconcile` function helps manage data changes by performing a diffing process, making it particularly handy in scenarios where applying granular updates is challenging or inefficient.
+
+The `key` and `merge` options provide flexibility to customize the reconciliation process based on specific needs.
+
+```ts
+// subscribing to an observable
+const unsubscribe = store.subscribe(({ todos }) => (
+ setState('todos', reconcile(todos));
+);
+onCleanup(() => unsubscribe());
+
+```
+
+##### Options
+
+| Option | Type | Default | Description |
+| ------ | ------- | ------- | ---------------------------------- |
+| key | string | "id" | Specifies the key to be used for matching items during reconciliation |
+| merge | boolean | false | When merge is false, referential checks are performed where possible to determine equality, and items that are not referentially equal are replaced. When merge is true, all diffing is pushed to the leaves, effectively morphing the previous data to the new value. |
+
+
+---
+title: unwrap
+---
+
+`unwrap` returns the underlying data in the store without a proxy.
+
+```tsx
+import { unwrap } from "solid-js/store"
+import type { Store } from "solid-js/store"
+
+function unwrap(store: Store): T
+```
+
+
+---
+title: "Auth"
+---
+
+Server functions can be used to protect sensitive resources like user data.
+
+```tsx
+"use server"
+
+async function getPrivatePosts() {
+ const user = await getUser()
+ if(!user) {
+ return null // or throw an error
+ }
+
+ return db.getPosts({ userId: user.id, private: true })
+}
+```
+
+The `getUser` function can be [implemented using sessions](/solid-start/advanced/session).
+
+## Protected Routes
+
+Routes can be protected by checking the user or session object during data fetching.
+This example uses [Solid Router](/solid-router).
+
+```tsx
+const getPrivatePosts = query(async function() {
+ "use server"
+ const user = await getUser()
+ if(!user) {
+ throw redirect("/login");
+ }
+
+ return db.getPosts({ userId: user.id, private: true })
+})
+
+export default function Page() {
+ const posts = createAsync(() => getPrivatePosts());
+}
+```
+
+Once the user hits this route, the router will attempt to fetch `getPrivatePosts` data.
+If the user is not signed in, `getPrivatePosts` will throw and the router will redirect to the login page.
+
+
+---
+title: "Middleware"
+---
+
+Middlewares may be included by passing file you specify in your start config.
+
+```js
+import { defineConfig } from "@solidjs/start/config";
+
+export default defineConfig({
+ middleware: "./src/middleware.ts"
+});
+```
+
+Inside the middleware file, you can export a `createMiddleware` function.
+
+```tsx
+import { createMiddleware } from "@solidjs/start/middleware";
+
+export default createMiddleware({
+ onRequest: [
+ event => {
+ console.log("GLOBAL", event.request.url);
+ }
+ ]
+});
+```
+
+Middleware supports 2 lifecycles: `onRequest` and `onBeforeResponse`. If you return a value from middleware it will respond with that, otherwise it will run the next one in the chain.
+
+---
+title: Request events
+---
+
+Request events in SolidStart are retrieved using the [`getRequestEvent`](/reference/server-utilities/get-request-event) from `@solidjs/web`.
+These requests happen anywhere on the server.
+
+## Locals
+
+SolidStart uses `event.locals` to pass around a local context where needed.
+
+When adding fields to `event.locals`, the fields can be typed:
+
+```tsx
+declare module "@solidjs/start/server" {
+ interface RequestEventLocals {
+ myNumber: number;
+ someString: string;
+ }
+}
+```
+
+## nativeEvent
+
+Sometimes access is still needed to the underlying event from [Vinxi](https://vinxi.vercel.app/).
+This can be accessed that using the `.nativeEvent` property, which is the underlying H3Event used, and can be passed to the helpers available in the ecosystem.
+Note that Vinxi HTTP helpers _do not_ treeshake so you can only import them in files that do not contain client or isomorphic code.
+
+Many of these events support Async Local Storage so this may not be needed.
+
+
+---
+title: Returning responses
+---
+
+In SolidStart, it is possible to return a Response object from a server function.
+[`solid-router`](/solid-router) knows how to handle certain responses with its [`cache`](/solid-router/reference/data-apis/cache) and [`action`](/solid-router/reference/data-apis/action) APIs.
+For Typescript, when returning a response using `solid-routers`'s `redirect`, `reload`, or `json` helpers, they will not impact the return value of the server function.
+
+While we suggest depending on the type of the function to handle errors differently, you can always return or throw a response.
+
+## Examples
+
+In the following example, the `hello` function will return a value of type `Promise<{ hello: string }>`:
+
+```tsx
+import { json } from "@solidjs/router";
+import { GET } from "@solidjs/start";
+
+const hello = GET(async (name: string) => {
+ "use server";
+ return json(
+ { hello: new Promise((r) => setTimeout(() => r(name), 1000)) },
+ { headers: { "cache-control": "max-age=60" } }
+ );
+});
+```
+
+However, in this example, since `redirect` and `reload` return `never` as their type, `getUser` can only return a value of type `Promise`:
+
+```tsx { 4, 10, 14}
+export async function getUser() {
+ "use server";
+
+ const session = await getSession();
+ const userId = session.data.userId;
+ if (userId === undefined) return redirect("/login");
+
+ try {
+ const user: User = await db.user.findUnique({ where: { id: userId } });
+ // throwing can awkward.
+ if (!user) return redirect("/login");
+ return user;
+ } catch {
+ // do stuff
+ throw redirect("/login");
+ }
+}
+```
+
+
+---
+title: "Sessions"
+---
+
+When user information is required, it is usually done by checking the request for information.
+The best way for the client and server to do that is using cookies.
+
+The `Request` object can be used to access the `Cookie` Headers, which can then be parsed to get the value for that specific cookie.
+For example, `"session"` can be used to identify the session.
+Fortunately, Nitro comes ready with helpers that enable this.
+
+For example, if you wanted to use a cookie to identify a user, you can use the `useSession` helper from `vinxi/http`:
+
+```tsx title="/lib/session.ts"
+import { useSession } from "vinxi/http";
+export async function getUser(request: Request) {
+ const session = await useSession({
+ password: process.env.SESSION_SECRET
+ });
+}
+```
+
+The session cookie can be used to get the session data about the request.
+How the session data is stored and retrieved, however, is up to the implementation of the `useSession`.
+
+Typically, `userId` will be saved in the session data and if it is not found, it indicates that the request was not authenticated.
+The `getUser` function returns a `null` when it does not find a user and if a user is found, it will be used to get the user from the database:
+
+```tsx title="/lib/session.ts"
+import { useSession } from "vinxi/http";
+
+export async function getUser(): Promise {
+ const session = await useSession({
+ password: process.env.SESSION_SECRET
+ });
+ const userId = session.data.userId;
+ if (!userId) return null;
+ return await store.getUser(userId);
+}
+```
+
+This helper can be used wherever you want to authenticate the request, including in server functions and [API routes](/solid-start/building-your-application/api-routes).
+
+Additionally, you can use it with [`cache`](/solid-router/reference/data-apis/cache) from `solid-router` to make sure that only authenticated users can access the data.
+That way if the user is not authenticated, the request will be redirected to the login page.
+
+```tsx title="/routes/api/store/admin.ts"
+import { query, createAsync, redirect } from "@solidjs/router";
+
+const getUsers = query(async (id: string) => {
+ "use server";
+ const user = await getUser();
+ if (!user) throw redirect("/login");
+ return store.getUsers(id, "*");
+}, "users");
+
+// page component
+export default function Users() {
+ const users = createAsync(() => getUsers());
+}
+```
+
+This also allows logging in and out of the session in a similar manner:
+
+```tsx title="/routes/session.server.ts"
+import { redirect } from "@solidjs/router";
+import { useSession } from "vinxi/http";
+
+type UserSession = {
+ userId?: number;
+};
+
+function getSession() {
+ return useSession({
+ password: process.env.SESSION_SECRET
+ });
+}
+
+export async function login(formData: FormData) {
+ const username = String(formData.get("username"));
+ const password = String(formData.get("password"));
+ // do validation
+ try {
+ const session = await getSession();
+ const user = await db.user.findUnique({ where: { username } });
+ if (!user || password !== user.password) return new Error("Invalid login");
+ await session.update((d: UserSession) => (d.userId = user!.id));
+ } catch (err) {
+ return err as Error;
+ }
+ throw redirect("/");
+}
+
+export async function logout() {
+ const session = await getSession();
+ await session.update((d: UserSession) => (d.userId = undefined));
+ throw redirect("/login");
+}
+```
+
+---
+title: WebSocket endpoint
+---
+
+WebSocket endpoint may be included by passing the ws handler file you specify in your start config.
+Note that this feature is [experimental on the Nitro server](https://nitro.unjs.io/guide/websocket#opt-in-to-the-experimental-feature) and its config may change in future releases of SolidStart. Use it with caution.
+
+```ts title="./app.config.ts"
+import { defineConfig } from "@solidjs/start/config";
+
+export default defineConfig({
+ server: {
+ experimental: {
+ websocket: true,
+ },
+ },
+}).addRouter({
+ name: "ws",
+ type: "http",
+ handler: "./src/ws.ts",
+ target: "server",
+ base: "/ws",
+});
+```
+
+Inside the ws file, you can export an eventHandler function to manage WebSocket connections and events:
+
+```tsx title="./src/ws.ts"
+import { eventHandler } from "vinxi/http";
+
+export default eventHandler({
+ handler() {},
+ websocket: {
+ async open(peer) {
+ console.log("open", peer.id, peer.url);
+ },
+ async message(peer, msg) {
+ const message = msg.text();
+ console.log("msg", peer.id, peer.url, message);
+ },
+ async close(peer, details) {
+ console.log("close", peer.id, peer.url);
+ },
+ async error(peer, error) {
+ console.log("error", peer.id, peer.url, error);
+ },
+ },
+});
+```
+
+
+---
+title: "API routes"
+---
+
+While Server Functions can be a good way to write server-side code for data needed by your UI, sometimes you need to expose API routes.
+Some reasons for wanting API Routes include:
+- There are additional clients that want to share this logic.
+- Exposing a GraphQL or tRPC endpoint.
+- Exposing a public facing REST API.
+- Writing webhooks or auth callback handlers for OAuth.
+- Having URLs not serving HTML, but other kinds of documents like PDFs or images.
+
+For these use cases, SolidStart provides a way to write these routes in a way that is easy to understand and maintain.
+API routes are just similar to other routes and follow the same filename conventions as [UI Routes](/solid-start/building-your-application/routing).
+
+The difference between API routes and UI routes is in what you should export from the file.
+UI routes export a default Solid component, while API Routes do not.
+Rather, they export functions that are named after the HTTP method that they handle.
+
+
+API routes are prioritized over page route alternatives.
+If you want to have them overlap at the same path remember to use `Accept` headers.
+Returning without a response in a `GET` route will fallback to page route handling.
+
+
+## Writing an API route
+
+To write an API route, you can create a file in a directory.
+While you can name this directory anything, it is common to name it `api` to indicate that the routes in this directory are for handling API requests:
+
+```tsx title="routes/api/test.ts"
+export function GET() {
+ // ...
+}
+
+export function POST() {
+ // ...
+}
+
+export function PATCH() {
+ // ...
+}
+
+export function DELETE() {
+ // ...
+}
+```
+
+API routes get passed an `APIEvent` object as their first argument.
+This object contains:
+- `request`: [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request) object representing the request sent by the client.
+- `params`: Object that contains the dynamic route parameters. For example, if the route is `/api/users/:id`, and the request is made to `/api/users/123`, then `params` will be `{ id: 123 }`.
+- `fetch`: An internal `fetch` function that can be used to make requests to other API routes without worrying about the `origin` of the URL.
+
+An API route is expected to return JSON or a `Response` object.
+In order to handle all methods, you can define a handler function that binds multiple methods to it:
+
+```tsx title="routes/api/all.ts"
+async function handler() {
+ // ...
+}
+
+export const GET = handler;
+export const POST = handler;
+// ...
+```
+
+An example of an API route that returns products from a certain category and brand is shown below:
+
+```tsx title="routes/api/product/[category]/[brand].ts"
+import type { APIEvent } from "@solidjs/start/server";
+import store from "./store";
+
+export async function GET({ params }: APIEvent) {
+ console.log(`Category: ${params.category}, Brand: ${params.brand}`);
+ const products = await store.getProducts(params.category, params.brand);
+ return products;
+}
+```
+
+## Session management
+
+Since HTTP is a stateless protocol, you need to manage the state of the session on the server.
+For example, if you want to know who the user is, the most secure way of doing this is through the use of HTTP-only cookies.
+Cookies are a way to store data in the user's browser that persist in the browser between requests.
+
+The user's request is exposed through the `Request` object.
+Through parsing the [`Cookie`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie) header, the cookies can be accessed and any helpers from `vinxi/http` can be used to make that a bit easier.
+
+```tsx
+import type { APIEvent } from "@solidjs/start/server";
+import { getCookie } from "vinxi/http";
+import store from "./store";
+
+export async function GET(event: APIEvent) {
+ const userId = getCookie("userId");
+ if (!userId) {
+ return new Response("Not logged in", { status: 401 });
+ }
+ const user = await store.getUser(event.params.userId);
+ if (user.id !== userId) {
+ return new Response("Not authorized", { status: 403 });
+ }
+ return user;
+}
+```
+
+In this example, you can see that the `userId` is read from the cookie and then used to look up the user in the store.
+For more information on how to use cookies for secure session management, read the [session documentation](/solid-start/advanced/session).
+
+## Exposing a GraphQL API
+
+SolidStart makes it easy to [implement a GraphQL API](https://graphql.org/).
+GraphQL is a query language for APIs and a runtime for executing those queries by using a type system you define for your data.
+
+To implement a GraphQL API, you need to define a schema and resolvers.
+The `graphql` function takes a GraphQL schema and returns a function that can be used as an API route handler.
+
+First, to implement a GraphQL API, install the `graphql` library.
+Following that, you can implement your schema and resolvers in a file and then export a handler function that will be used as the API route:
+
+```tsx title="routes/graphql.ts"
+import { buildSchema, graphql } from "graphql";
+import type { APIEvent } from "@solidjs/start/server";
+
+// Define GraphQL Schema
+const schema = buildSchema(`
+ type Message {
+ message: String
+ }
+
+ type Query {
+ hello(input: String): Message
+ goodbye: String
+ }
+`);
+
+// Define GraphQL Resolvers
+const rootValue = {
+ hello: () => {
+ return {
+ message: "Hello World"
+ };
+ },
+ goodbye: () => {
+ return "Goodbye";
+ }
+};
+
+// request handler
+const handler = async (event: APIEvent) => {
+ // get request body
+ const body = await new Response(event.request.body).json();
+
+ // pass query and save results
+ const result = await graphql({ rootValue, schema, source: body.query });
+
+ // send query result
+ return result;
+};
+
+export const GET = handler;
+
+export const POST = handler;
+```
+
+## Exposing a tRPC server route
+
+[tRPC](https://trpc.io/) is a modern TypeScript-first API framework that is designed to be easy to use and understand.
+
+To expose a tRPC server route, you need to write your router.
+Once you have written your router, you can put it in a separate file so that you can export the type for your client.
+
+```tsx title="lib/router.ts"
+import { initTRPC } from "@trpc/server";
+import { wrap } from "@decs/typeschema";
+import { string } from "valibot";
+
+const t = initTRPC.create();
+
+export const appRouter = t.router({
+ hello: t.procedure.input(wrap(string())).query(({ input }) => {
+ return `hello ${input ?? "world"}`;
+ })
+});
+
+export type AppRouter = typeof appRouter;
+```
+
+An example of a simple client that you can use to fetch data from your tRPC server is shown below:
+
+```tsx title="lib/trpc.ts"
+import { createTRPCProxyClient, httpBatchLink, loggerLink } from "@trpc/client";
+import type { AppRouter } from "./router";
+
+export const client = createTRPCProxyClient({
+ links: [loggerLink(), httpBatchLink({ url: "http://localhost:3000/api/trpc" })]
+});
+```
+
+Finally, you can use the `fetch` adapter to write an API route that acts as the tRPC server.
+
+```tsx title="routes/api/trpc/[trpc].ts"
+import { type APIEvent } from "@solidjs/start/server";
+import { fetchRequestHandler } from "@trpc/server/adapters/fetch";
+import { appRouter } from "~/lib/router";
+
+const handler = (event: APIEvent) =>
+ fetchRequestHandler({
+ endpoint: "/api/trpc",
+ req: event.request,
+ router: appRouter,
+ createContext: () => ({})
+ });
+
+export const GET = handler;
+
+export const POST = handler;
+```
+
+To learn more about tRPC, you can read the [tRPC documentation](https://trpc.io/docs).
+
+
+---
+title: "CSS and styling"
+---
+
+SolidStart is a standards-based framework that, instead of modifying the behavior of the [`
{local.children}
+ {value}
+ }
+}
+```
+
+## Initial and Default Values
+
+It is not necessary to manually untrack values that are suppose to serve as a default or initial value to a signal. Even with the linter configured to enforce tracking, the linter will accept it when a `prop` is prefixed with `default` or `initial` as it is a common pattern to use them as such.
+
+
+
+```tsx title="component.tsx" {4}
+import { createSignal } from "solid-js"
+
+export function Component(props) {
+ const [name, setName] = createSignal(props.initialName)
+
+ return
+
+{name()}
+ }
+}
+```
+
+
+```tsx title="component.tsx" {4}
+import { createSignal } from "solid-js"
+
+export function Component(props) {
+ const [name, setName] = createSignal(props.defaultName)
+
+ return
+{name()}
+ }
+}
+```
+