SolidJS Project Rules

solidjsfrontendjavascript

Enforces SolidJS patterns including fine-grained reactivity, signals, stores, and component conventions for high-performance reactive web applications.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

## SolidJS Project Rules ### Reactivity Fundamentals - Signals are the atomic unit of state: `const [count, setCount] = createSignal(0)` - Always call signals as functions to read their value: `count()` not `count` - Do not destructure signals — you lose reactivity: `const { x } = obj` breaks if `obj` is a signal - Derived values must use `createMemo()` — never compute derived state inline in JSX - Side effects must use `createEffect()` — never use raw function calls for reactive side effects - `createEffect` tracks all signals accessed during its first synchronous run ### Component Patterns - SolidJS components run exactly once — never rely on re-renders - Props are reactive getter/setter pairs; always access props inside JSX or effects, not destructured at top level - Use `props.children` directly — do not cache it in a variable outside JSX - Use `splitProps()` to separate component-specific props from native element props - Use `mergeProps()` to apply default prop values reactively ### Control Flow - Use `<Show when={condition()}>` instead of ternary expressions for conditional rendering - Use `<For each={list()}>` instead of `Array.map()` — it reconciles by item identity, not index - Use `<Index each={list()}>` when the array position is the key, not the item - Use `<Switch>` / `<Match>` for multi-branch conditionals - Use `<Suspense>` with `createResource()` for async data with loading states - Use `<ErrorBoundary>` around any component that may throw during render ### Stores - Use `createStore()` for nested/object state that needs granular updates - Update stores with `setStore()` using path-based updates: `setStore('user', 'name', 'Alice')` - Use `produce()` (immer-style) for complex mutations on stores - Do not mutate store objects directly — always use the setter - Use `unwrap()` to get a plain non-reactive snapshot of a store ### Resources & Async - Use `createResource(fetcher)` for all async data fetching - Resources expose `.loading`, `.error`, `.latest` for handling fetch states - Pass a source signal as the first argument to `createResource` for dependent fetching - Use `refetch()` from resource to manually trigger re-fetch ### Lifecycle & Cleanup - Use `onMount()` for code that runs after the component is first rendered to the DOM - Use `onCleanup()` inside effects and resources to dispose subscriptions and timers - Do not use `onMount` for reactive side effects — use `createEffect` - Cleanup functions in `createEffect` run before the effect re-runs and on unmount ### Context & Dependency Injection - Use `createContext()` and `useContext()` for dependency injection down the tree - Always provide a default value or check for undefined in `useContext()` - Create context in a separate file and export typed `useMyContext()` wrapper ### Performance - Fine-grained reactivity means only the DOM nodes tied to a signal update — trust it - Avoid `createMemo` for cheap computations — use it for expensive derived values - Use keyed `<For>` loops; avoid index-based keys that cause unnecessary DOM churn - Prefer co-locating signal reads as close to the DOM as possible for minimal re-evaluation ### Anti-patterns - Do not read a signal outside a reactive context (effect, memo, JSX) — it will not track - Do not put signal reads in event handlers expecting reactivity — those are one-time reads - Do not use `React`-style patterns (`useState` with closures over stale state) — Solid signals are always current - Do not spread reactive objects as props without `splitProps` — you lose reactivity

CLI

npx mindaxis apply solidjs-rules --target cursor --scope project

Используется в паках

Frontend Build Tooling

Vite, Webpack, Turbo, and modern frontend build pipeline setup

Открыть пак →

← Правила