deferred-jsx-props

Types deferred JSX markup as thunk functions to prevent SolidJS disposal warnings.

2|1|Updated Jun 28, 2026
One-click install
npx skills add https://github.com/lxsmnsyc/overwander --skill deferred-jsx-props-lxsmnsyc
Or copy as Structured Prompt for Agentβ–Ό
Please help me install this Agent Skill.
Skill: deferred-jsx-props
Source: https://github.com/lxsmnsyc/overwander/tree/main/.agents/skills/deferred-jsx-props
Command: npx skills add https://github.com/lxsmnsyc/overwander --skill deferred-jsx-props-lxsmnsyc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? In SolidJS, JSX constructed outside a render (in event handlers, promises, or timeouts) creates computations with no owner that are never disposed, triggering the "computations created outside a createRoot or render will never be disposed" warning. This Skill defines the typing rule that prevents it. ## Core Features & Use Cases - Typing rule for deferred markup: Any prop whose markup is built outside a render β€” pushed onto a queue, held in a signal, or sent from a promise β€” must be typed () => JSX.Element, never JSX.Element. - Distinction from plain props: Markup passed parent to child stays JSX.Element, because the compiler wraps it in a getter evaluated inside the parent's render, which has an owner. - Use Case: A toast system where callers push toast.push({ art: () => <ItemSprite item={stack.item} size={24} label="" /> }) so the JSX is constructed under the card that draws it, with the holder rendering it via an explicit call like {props.toast.art?.()}. ## Quick Start When adding a prop or API that stores markup and draws it later, type it as a zero-argument function returning JSX.Element and have the holder call it where it renders.

Frequently Asked Questions about deferred-jsx-props

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix "computations created outside a createRoot or render will never be disposed" in SolidJS?β–Ό

Type the stored markup as `() => JSX.Element` instead of `JSX.Element`, and call it where it is drawn. Constructing JSX inside a render gives its memos an owner; constructing it in a handler or promise leaves them undisposed.

When should a SolidJS prop be () => JSX.Element instead of JSX.Element?β–Ό

Use `() => JSX.Element` whenever the markup is built outside a render β€” pushed onto a queue, held in a signal, or sent from a promise. Markup passed directly parent to child stays `JSX.Element` because the compiler evaluates it inside the parent's render.

Why does SolidJS warn about computations created outside a render?β–Ό

Solid's compiler wraps dynamic props in memos when the element is constructed. Elements built in event handlers, `.then` callbacks, or `setTimeout` have no owner, so those memos live for the life of the page and are never disposed.

How do I render a JSX thunk prop in a SolidJS component?β–Ό

Call it explicitly at the draw site, for example `{props.toast.art?.()}` inside a `<Show when={props.toast.art != null}>` guard. The holder invokes the thunk so the JSX is constructed under the rendering component's owner.

Does this JSX thunk rule apply to normal parent-to-child props in SolidJS?β–Ό

No. Plain props like `title`, `trigger`, or `footer` passed parent to child remain `JSX.Element`, because the compiler makes them getters evaluated inside the parent's render, which has an owner. The rule only covers markup stored and drawn later.