Conditional Rendering
Use conditional rendering with the current published Askr packages.
@askrjs/askr0.0.59
How to use conditional rendering
Use Show for a boolean branch and Match/Case when one value selects several mutually exclusive views.
- Import the published @askrjs/askr entrypoint.
- Keep conditional rendering configuration next to the component, route, or server composition root that owns it.
- Handle pending, unavailable, cancellation, and failure states, then verify the production path.
import { Case, Match, Show } from '@askrjs/askr';
<Show when={project()} fallback={<ProjectSkeleton />}>
{(project) => <ProjectDetails project={project} />}
</Show>
<Match value={status()}>
<Case when="ready"><ReadyState /></Case>
<Case when="failed"><FailureState /></Case>
</Match>Show
`<Show when={value} fallback={...}>{children}</Show>` renders its children when `when` is truthy and the fallback otherwise. `when` accepts a plain value or a function, and when children is a function it receives the narrowed truthy value directly — so `<Show when={user}>{u => <p>{u.name}</p>}</Show>` skips a separate null check inside the block.
Match
`Match` is a declarative branch used as a child of `Case`: `<Match when={status === 'ready'}>...</Match>` describes one condition and its content but doesn't render on its own — the component itself returns `null` and only exists so `Case` can read its `when` and `children` from the JSX tree. Each `Match` can carry an optional `key` when the branch's content needs stable identity across switches.
Case
`Case` is the switch-style counterpart to `Show`: wrap a set of `Match` children in `<Case fallback={...}>` and Askr renders whichever `Match`'s `when` is truthy first, falling through to `fallback` if none match. It's the right tool once a condition has more than two real outcomes — three or four `Show`s nested inside each other get harder to read than one `Case` with explicit branches.
Fallback content
Both `Show` and `Case` accept a `fallback` prop for the not-matched case, and `For` accepts one for the empty-collection case — all three take the same kind of renderable content, so a loading spinner or empty-state component can be shared across them. Fallback content unmounts and its DOM is torn down the moment a real branch becomes active, so it's not a good place to keep state you want to persist across the switch.