SolidJS Complete Guide: Fine-Grained Reactive UI Framework (2026)

SolidJS is a declarative JavaScript library for building user interfaces that compiles down to real DOM operations with no virtual DOM overhead. Its fine-grained reactivity system tracks exactly which parts of the UI depend on which pieces of state, updating only the precise DOM nodes that need to change. SolidJS delivers performance on par with hand-optimized vanilla JavaScript while offering a component model and JSX syntax familiar to React developers.

What Is SolidJS and Fine-Grained Reactivity?

SolidJS is a UI library created by Ryan Carniato that takes a fundamentally different approach from React. While React uses a virtual DOM to diff and batch updates, Solid compiles your JSX templates into efficient real DOM creation and update code. There is no reconciliation step and no diffing algorithm. When a signal changes, only the specific DOM text node, attribute, or class list that reads that signal is updated directly.

Fine-grained reactivity means the framework tracks dependencies at the individual expression level, not at the component level. A component function in Solid executes exactly once to set up the reactive graph. After that, updates flow through the graph automatically without re-running the component. This eliminates the need for memoization hooks like useMemo or useCallback because closures never go stale.

// How Solid compiles JSX - conceptual overview
// Your JSX code:
function Counter() {
  const [count, setCount] = createSignal(0);
  return <button onClick={() => setCount(c => c + 1)}>
    Clicks: {count()}
  </button>;
}

// Solid compiles this to (simplified):
function Counter() {
  const [count, setCount] = createSignal(0);
  const button = document.createElement("button");
  button.onclick = () => setCount(c => c + 1);
  const text = document.createTextNode("");
  // Only this expression re-runs when count changes:
  createEffect(() => text.data = "Clicks: " + count());
  button.appendChild(text);
  return button;
}

SolidJS vs React: Key Differences

While Solid and React share JSX syntax and a component-based architecture, their execution models are fundamentally different. Understanding these differences is essential for writing idiomatic Solid code.

Signals, Memos, and Effects

Solid provides three core reactive primitives that form the foundation of all state management. Signals hold reactive values, memos derive computed values efficiently, and effects run side effects when their dependencies change.

createSignal: Reactive State

A signal is a reactive value container that returns a getter function and a setter function. Reading the getter inside a reactive context (like JSX or an effect) automatically subscribes to changes. The setter triggers updates only to the exact subscribers.

import { createSignal } from "solid-js";

function Counter() {
  // Returns [getter, setter] - getter is a function!
  const [count, setCount] = createSignal(0);
  const [name, setName] = createSignal("World");

  return (
    <div>
      {/* count() calls the getter function */}
      <p>Count: {count()}</p>
      <p>Hello, {name()}!</p>

      {/* Setter accepts value or updater function */}
      <button onClick={() => setCount(count() + 1)}>+1</button>
      <button onClick={() => setCount(c => c + 1)}>+1 (updater)</button>
      <input
        value={name()}
        onInput={(e) => setName(e.target.value)}
      />
    </div>
  );
}

createMemo: Derived Computations

A memo is a cached derived value that only recalculates when its dependencies change. Unlike React useMemo, Solid memos are truly reactive and participate in the dependency graph. They prevent redundant computations in complex reactive chains.

import { createSignal, createMemo } from "solid-js";

function FilteredList() {
  const [items, setItems] = createSignal([
    { name: "Apple", category: "fruit" },
    { name: "Carrot", category: "vegetable" },
    { name: "Banana", category: "fruit" },
  ]);
  const [filter, setFilter] = createSignal("fruit");

  // Only recalculates when items() or filter() change
  const filtered = createMemo(() =>
    items().filter(item => item.category === filter())
  );

  // Derived from memo - cached, no redundant work
  const count = createMemo(() => filtered().length);

  return (
    <div>
      <p>Showing {count()} items</p>
      <For each={filtered()}>
        {(item) => <p>{item.name}</p>}
      </For>
    </div>
  );
}

createEffect: Side Effects

An effect runs a function whenever its tracked dependencies change. It automatically detects which signals it reads and re-runs only when those specific signals update. Effects are useful for DOM manipulation, logging, network requests, and other side effects.

import { createSignal, createEffect, onCleanup } from "solid-js";

function Timer() {
  const [count, setCount] = createSignal(0);
  const [running, setRunning] = createSignal(false);

  // Effect tracks running() automatically
  createEffect(() => {
    if (running()) {
      const id = setInterval(() => setCount(c => c + 1), 1000);
      // Cleanup runs before next effect or on disposal
      onCleanup(() => clearInterval(id));
    }
  });

  // Effect for document title - tracks count()
  createEffect(() => {
    document.title = "Count: " + count();
  });

  return (
    <div>
      <p>{count()}</p>
      <button onClick={() => setRunning(r => !r)}>
        {running() ? "Stop" : "Start"}
      </button>
    </div>
  );
}

Components and JSX (No Virtual DOM)

Solid components are plain functions that return JSX. The critical difference from React is that a Solid component function runs exactly once. It sets up the reactive bindings and returns the DOM structure. After that initial run, only the reactive expressions within the JSX update when their dependencies change.

Because components do not re-execute, there are no stale closures, no dependency arrays, and no need for useCallback or useMemo. Props are accessed as getter functions under the hood, so destructuring props at the top level would break reactivity. Always access props inside JSX or reactive contexts.

import { createSignal } from "solid-js";

// Props must NOT be destructured at parameter level
// BAD:  function Greeting({ name, greeting }) { ... }
// GOOD: function Greeting(props) { ... }

function Greeting(props: { name: string; greeting?: string }) {
  // Access props inside JSX to keep reactivity
  return (
    <p>{props.greeting || "Hello"}, {props.name}!</p>
  );
}

function App() {
  const [name, setName] = createSignal("Solid");

  // This component function runs ONCE
  console.log("App setup - runs only once");

  return (
    <div>
      {/* When name() changes, only the text node updates */}
      <Greeting name={name()} greeting="Welcome" />
      <input
        value={name()}
        onInput={(e) => setName(e.target.value)}
      />
    </div>
  );
}

Control Flow Components

Solid provides built-in control flow components instead of relying on JavaScript expressions like ternary operators or Array.map. These components are optimized for fine-grained reactivity and ensure that DOM nodes are created, destroyed, or moved efficiently.

Show: Conditional Rendering

The Show component renders its children when a condition is truthy. It supports a fallback prop for the else case. Unlike a ternary expression, Show only creates the truthy or falsy branch, not both.

import { Show, createSignal } from "solid-js";

function UserProfile() {
  const [user, setUser] = createSignal(null);
  const [loading, setLoading] = createSignal(true);

  return (
    <div>
      <Show when={loading()} fallback={
        <Show when={user()} fallback={<p>No user found</p>}>
          {(u) => (
            <div>
              <h2>{u().name}</h2>
              <p>{u().email}</p>
            </div>
          )}
        </Show>
      }>
        <p>Loading...</p>
      </Show>
    </div>
  );
}

For: List Rendering

The For component iterates over an array and renders each item. It uses referential identity to track items, so it only updates the DOM nodes for items that actually changed rather than re-rendering the entire list.

import { For, createSignal } from "solid-js";

function TodoList() {
  const [todos, setTodos] = createSignal([
    { id: 1, text: "Learn Solid", done: false },
    { id: 2, text: "Build an app", done: false },
  ]);

  const addTodo = (text: string) => {
    setTodos(prev => [...prev, {
      id: Date.now(), text, done: false
    }]);
  };

  return (
    <ul>
      {/* For tracks items by reference */}
      <For each={todos()}>
        {(todo, index) => (
          <li>
            {index() + 1}. {todo.text}
            {todo.done ? " (done)" : ""}
          </li>
        )}
      </For>
    </ul>
  );
}

Switch/Match: Multi-Branch Conditions

Switch and Match provide a pattern-matching style conditional that is cleaner than nested ternaries. Only the first matching branch renders.

import { Switch, Match, createSignal } from "solid-js";

function StatusBadge() {
  const [status, setStatus] = createSignal("loading");

  return (
    <Switch fallback={<span>Unknown status</span>}>
      <Match when={status() === "loading"}>
        <span style={{ color: "orange" }}>Loading...</span>
      </Match>
      <Match when={status() === "success"}>
        <span style={{ color: "green" }}>Success</span>
      </Match>
      <Match when={status() === "error"}>
        <span style={{ color: "red" }}>Error</span>
      </Match>
    </Switch>
  );
}

Stores and Nested Reactivity

For complex state with nested objects and arrays, Solid provides stores. A store is a deeply reactive proxy object where each property is individually tracked. This means updating a deeply nested field only triggers updates for the specific parts of the UI that read that field.

Stores use a path-based setter API that makes immutable-style updates ergonomic. You describe the path to the property you want to update, and Solid handles the reactive notification precisely.

import { createStore, produce } from "solid-js/store";

function TodoApp() {
  const [state, setState] = createStore({
    user: { name: "Alice", theme: "dark" },
    todos: [
      { id: 1, text: "Learn Solid stores", done: false },
      { id: 2, text: "Build something", done: false },
    ],
    filter: "all" as "all" | "active" | "done",
  });

  // Path-based updates - only affected subscribers update
  const toggleTodo = (id: number) => {
    setState("todos", t => t.id === id, "done", d => !d);
  };

  // Using produce for mutable-style syntax
  const addTodo = (text: string) => {
    setState(produce(s => {
      s.todos.push({ id: Date.now(), text, done: false });
    }));
  };

  // Nested update - only rerenders theme subscribers
  const toggleTheme = () => {
    setState("user", "theme", t => t === "dark" ? "light" : "dark");
  };

  return (
    <div>
      <p>Theme: {state.user.theme}</p>
      <For each={state.todos}>
        {(todo) => (
          <div onClick={() => toggleTodo(todo.id)}>
            {todo.text} {todo.done ? "(done)" : ""}
          </div>
        )}
      </For>
    </div>
  );
}

Context and Dependency Injection

Solid provides a context API similar to React for passing data through the component tree without prop drilling. Because Solid components run once, context values are read once during setup. If the context value is a signal or store, downstream consumers still react to changes automatically.

import { createContext, useContext, createSignal } from "solid-js";
import type { ParentComponent } from "solid-js";

// Define the context with a type
type ThemeContextType = {
  theme: () => string;
  setTheme: (t: string) => void;
};

const ThemeContext = createContext<ThemeContextType>();

// Provider component
const ThemeProvider: ParentComponent = (props) => {
  const [theme, setTheme] = createSignal("light");
  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {props.children}
    </ThemeContext.Provider>
  );
};

// Consumer hook
function useTheme() {
  const ctx = useContext(ThemeContext);
  if (!ctx) throw new Error("useTheme: no ThemeProvider");
  return ctx;
}

// Usage in a component
function ThemeToggle() {
  const { theme, setTheme } = useTheme();
  return (
    <button onClick={() => setTheme(
      theme() === "light" ? "dark" : "light"
    )}>
      Current: {theme()}
    </button>
  );
}

SolidStart: The Meta-Framework

SolidStart is the official meta-framework for SolidJS, comparable to Next.js for React or Nuxt for Vue. It provides file-based routing, server-side rendering, streaming, API routes, and build optimizations powered by Vinxi and Nitro under the hood.

SolidStart supports multiple rendering modes including SSR with streaming, static site generation, and client-side rendering. It uses Vinxi as its server layer, giving access to the entire Nitro ecosystem of deployment adapters for Vercel, Netlify, Cloudflare, and more.

File-Based Routing

Routes are defined by the file structure in the src/routes directory. SolidStart supports dynamic parameters, catch-all routes, route groups, and nested layouts.

// SolidStart file-based routing structure
src/routes/
  index.tsx          // -> /
  about.tsx          // -> /about
  blog/
    index.tsx        // -> /blog
    [slug].tsx       // -> /blog/:slug
  users/
    [id].tsx         // -> /users/:id
    [...rest].tsx    // -> /users/* (catch-all)
  (auth)/            // route group (no URL segment)
    login.tsx        // -> /login
    register.tsx     // -> /register

// src/routes/blog/[slug].tsx
import { useParams } from "@solidjs/router";
import { createAsync } from "@solidjs/router";

const getPost = async (slug: string) => {
  "use server";
  return db.query("SELECT * FROM posts WHERE slug = ?", [slug]);
};

export default function BlogPost() {
  const params = useParams();
  const post = createAsync(() => getPost(params.slug));

  return (
    <Show when={post()}>
      {(p) => (
        <article>
          <h1>{p().title}</h1>
          <div innerHTML={p().content} />
        </article>
      )}
    </Show>
  );
}

Server Functions

SolidStart provides server functions that run exclusively on the server but can be called from client code. They are defined using the "use server" directive and are ideal for database queries, authentication, and API integrations.

// Server functions with "use server" directive
import { action, redirect } from "@solidjs/router";

// Server function for data fetching
async function getUsers() {
  "use server";
  return db.query("SELECT id, name, email FROM users");
}

// Server action for mutations
const createUser = action(async (formData: FormData) => {
  "use server";
  const name = formData.get("name") as string;
  const email = formData.get("email") as string;
  await db.query(
    "INSERT INTO users (name, email) VALUES (?, ?)",
    [name, email]
  );
  throw redirect("/users");
});

// Using in a component
export default function NewUser() {
  return (
    <form action={createUser} method="post">
      <input name="name" placeholder="Name" />
      <input name="email" type="email" placeholder="Email" />
      <button type="submit">Create User</button>
    </form>
  );
}

Resource API for Async Data

The createResource primitive handles async data fetching with built-in loading and error states. It integrates with Suspense for declarative loading UI and with SolidStart server functions for SSR-friendly data fetching.

import { createResource, createSignal, Suspense, ErrorBoundary } from "solid-js";

const fetchUser = async (id: number) => {
  const res = await fetch("/api/users/" + id);
  if (!res.ok) throw new Error("Failed to fetch user");
  return res.json();
};

function UserCard() {
  const [userId, setUserId] = createSignal(1);

  // Re-fetches when userId() changes
  const [user, { refetch, mutate }] = createResource(
    userId,
    fetchUser
  );

  return (
    <ErrorBoundary fallback={(err) => <p>Error: {err.message}</p>}>
      <Suspense fallback={<p>Loading user...</p>}>
        <Show when={user()}>
          {(u) => (
            <div>
              <h2>{u().name}</h2>
              <p>{u().email}</p>
              <button onClick={refetch}>Refresh</button>
            </div>
          )}
        </Show>
      </Suspense>
      <button onClick={() => setUserId(id => id + 1)}>
        Next User
      </button>
    </ErrorBoundary>
  );
}

TypeScript Integration

SolidJS has first-class TypeScript support. Signals, stores, components, and all APIs are fully typed. The JSX type system uses a custom JSX namespace that maps to real DOM element types rather than React synthetic events.

Component props are typed using standard TypeScript interfaces or type aliases. Generic components, discriminated unions in props, and strict event typing all work naturally.

import { Component, JSX } from "solid-js";

// Typed component props
interface ButtonProps {
  variant: "primary" | "secondary" | "danger";
  size?: "sm" | "md" | "lg";
  disabled?: boolean;
  onClick?: JSX.EventHandlerUnion<HTMLButtonElement, MouseEvent>;
  children: JSX.Element;
}

const Button: Component<ButtonProps> = (props) => {
  return (
    <button
      disabled={props.disabled}
      onClick={props.onClick}
      data-variant={props.variant}
      data-size={props.size || "md"}
    >
      {props.children}
    </button>
  );
};

Performance Benchmarks: Why Solid Is Fast

SolidJS consistently ranks at the top of JavaScript framework benchmarks. In the JS Framework Benchmark, Solid performs within a few percent of hand-optimized vanilla JavaScript implementations. Here is why:

• No virtual DOM overhead: updates go directly to the real DOM without a diffing step.
• Compile-time optimization: JSX is compiled to efficient DOM creation code, not generic createElement calls.
• Fine-grained tracking: only the exact expressions that depend on changed data are re-evaluated.
• No component re-execution: the component function runs once, so there is no overhead from re-rendering entire subtrees.
• Minimal memory allocation: no intermediate virtual DOM tree structures are allocated on updates.
• Small bundle: Solid core is roughly 7 KB gzipped, compared to 42 KB for React plus ReactDOM.

// Benchmark-style comparison (conceptual)
// Creating 1000 rows and updating every 10th row

// React: re-renders entire list component
// - Calls component function
// - Creates new virtual DOM tree (1000 nodes)
// - Diffs old vs new tree
// - Patches 100 real DOM nodes

// Solid: updates only affected DOM nodes
// - No component re-execution
// - No virtual DOM tree allocation
// - No diffing algorithm
// - Directly updates 100 text nodes via signal subscriptions

// JS Framework Benchmark results (lower is better):
// vanilla JS:    1.00 (baseline)
// Solid:         1.04
// Svelte:        1.19
// Vue:           1.36
// React:         1.55
// Angular:       1.42

Ecosystem and Community

The Solid ecosystem has grown rapidly and includes key libraries for common development needs:

• solid-router - Official routing library with nested routes, lazy loading, and data functions.
• solid-primitives - A collection of high-quality reactive utility primitives (media queries, intersection observer, storage, etc.).
• Kobalte - Accessible, unstyled UI component library (similar to Radix for React).
• solid-query - Powerful async state management for data fetching with caching.
• solid-testing-library - Testing utilities following the Testing Library philosophy.
• solid-transition-group - Animation and transition components for enter/exit animations.
• solid-markdown - Markdown renderer component for Solid applications.

// Getting started with SolidJS
# Create a new Solid project
npx degit solidjs/templates/ts my-solid-app
cd my-solid-app
npm install
npm run dev

# Create a SolidStart project
npm init solid@latest my-solid-start-app
cd my-solid-start-app
npm install
npm run dev

# Key packages to install
npm install @solidjs/router          # routing
npm install solid-primitives          # utility primitives
npm install @kobalte/core            # UI components

Migration from React to Solid

Migrating from React to Solid is more approachable than moving to a completely different paradigm because both use JSX and component-based architecture. However, several key mental model shifts are required:

• Replace useState with createSignal. Remember that the getter is a function that must be called: count() not count.
• Replace useEffect with createEffect. No dependency arrays are needed because Solid tracks dependencies automatically.
• Replace useMemo with createMemo. No dependency arrays needed.
• Do not destructure props. Access them as props.name inside JSX or reactive contexts to preserve reactivity.
• Replace conditional rendering ternaries with the Show component. Replace array.map with the For component.
• Remove useCallback entirely. Closures in Solid never go stale because components do not re-execute.
• Replace useRef with a simple let variable for DOM references. Use ref callback to assign them.

// React version                          // Solid equivalent
// useState("") + dep arrays              // createSignal("") - no dep arrays
// useMemo(() => ..., [items, query])      // createMemo(() => ...)
// useCallback((e) => ..., [])             // Not needed in Solid
// useEffect(() => ..., [filtered.length]) // createEffect(() => ...)
// value={query}                           // value={query()}
// onChange={handler}                      // onInput={e => setQuery(...)}
// filtered.map(i => <p key={i.id}>...)    // <For each={filtered()}>...

import { createSignal, createMemo, createEffect, For } from "solid-js";

function SearchSolid(props) {
  const [query, setQuery] = createSignal("");
  const filtered = createMemo(
    () => props.items.filter(i => i.name.includes(query()))
  );
  createEffect(() => {
    document.title = "Results: " + filtered().length;
  });

  return (
    <div>
      <input value={query()} onInput={e => setQuery(e.target.value)} />
      <For each={filtered()}>
        {(i) => <p>{i.name}</p>}
      </For>
    </div>
  );
}

Best Practices

Follow these patterns for idiomatic and performant SolidJS code:

• Never destructure props at the function parameter level. Use props.x inside JSX or wrap with splitProps/mergeProps.
• Use createMemo for expensive derived computations to avoid recalculating on every read.
• Prefer stores over multiple signals for complex nested state to get automatic deep reactivity.
• Use the For component for lists instead of array.map to get proper keyed updates and minimal DOM operations.
• Use Show for conditional rendering instead of ternary expressions to avoid creating both branches.
• Place createEffect calls at the component level, not inside conditionals or loops.
• Use onCleanup inside effects to properly dispose of subscriptions, timers, and event listeners.
• Leverage Suspense and ErrorBoundary for declarative async and error handling.
• Prefer batch() when setting multiple signals synchronously to avoid intermediate updates.
• Use lazy() for code splitting components in SolidStart routes to reduce initial bundle size.

Frequently Asked Questions