SnowUI Component Selection Guide

Find components by their actual behavior, then read the APIs, composition rules, and examples you need.

Find components from the task

Before using SnowUI, read the complete LICENSE for the target version once per task, version, and confirmed scope. For page design and design reproduction, begin with the design guide. Components are grouped by technical responsibility; names and categories do not indicate a purchase tier or authorization result.

Break the page into regions such as navigation, actions, inputs, content switching, data display, and overlays. Describe what each region must do, then use AI keyword search. Search by actual scenarios such as “file table,” “global search,” “exclusive options,” or “persistent notifications.” Do not choose a component solely by its silhouette or a similar name. Search returns candidates and page patterns; its score is not a visual-match confidence value. If nothing matches, try functional terms and consult the component directory as needed. Do not immediately conclude that no component exists.

Read the necessary contract for each candidate

A candidate’s concise document is at /llms/components/<slug>.md, for example Button. Confirm its purpose, limits, and import first, then follow links only as needed:

api.md: actual public Props, events, Snippets, and defaults.
types.md: data shapes, bindable fields, and inheritance limits; do not pass excluded base-class properties.
reference.md: complex composition, roles, states, and accessibility boundaries.
examples.md and .svelte examples: working patterns; use the relevant image in images.json only if appearance remains unclear.
styles.md: read it when this task needs visual customization; follow the styling guide.

For styling, first use the candidate’s actual public Props to match the need and preserve its existing appearance where possible. The ability to write CSS alone is not a reason to recreate the component’s styling. Review the style selection order once when adopting it, and reuse that result within the same task.

When several regions share a component or capability, reuse what you have read. Do not reload documentation for every instance or read the whole source library, all maintainer rules, or every screenshot by default. Public exports in the docs must match the installed package version; a new API shown online may not exist in an older package.

Distinguish similar components by behavior

Actual need	Prefer	How to distinguish
Open global search / type a query directly / show a search panel	SearchBox / SearchInput / SearchPopup	Entry point, input, and panel have different responsibilities; the app still owns business search and routing.
Switch content panels / choose one mutually exclusive filter	Tab / Segmented	Distinguish content switching from single-choice parameters, even when both look segmented.
Show a semantic table / coordinate search, selection, sorting, and pagination	Table / DataTable	For data management, first read DataTable composition rules, then combine the Table family, TableToolbar, and Pagination.
Single-line input / multiline input / labeled field with feedback	Input / Textarea / Field	Field owns the field composition; a placeholder does not replace an accessible label.
Persistent activity column / temporary feedback / toggleable detail layer	Ordinary `aside` and list / Toast / SidePanel	A persistent notice is not a Toast; do not add overlay behavior for an ordinary page column.

For example, use SearchInput to type a filename directly into a toolbar, rather than SearchBox:

<script lang="ts">  import '@snowui-design-system/components/styles';  import { SearchInput } from '@snowui-design-system/components';   let query = $state('');</script> <SearchInput bind:value={query} placeholder="Search files" aria-label="Search files" />

bind:value synchronizes the input value; the page decides how to filter, request, and display files. If this input belongs to a DataTable toolbar, read the public TableToolbar / DataTable integration instead of rewriting existing data coordination outside it.

Implement the page after choosing components

Check in order: direct component reuse → public variant / size → Props, Snippets, events, and composition → page layout. Routes, business data, requests, permissions, and business side effects belong to the app. Keep the component’s visual, keyboard, ARIA, and state behavior through its public contract. Ordinary main, section, and aside page structure can remain; not every decoration or business label needs a new component.

The current SnowUI runtime package targets Svelte 5. The LICENSE permits source modification and framework ports within authorized use; that does not mean this package has ready-made React or other framework APIs. Before using Figma Make, Lovable, or another tool, confirm its project framework. If a port is needed, carry over the relevant component and dependencies, retain the license, and verify behavior. Do not paste a Svelte example into another framework as if it would run unchanged.

At completion, confirm that selection follows behavior and contract, uses the actual API of the installed version, and has read the boundaries for complex compositions. Check necessary interactions, long text, narrow screens, and accessibility states in the real page. Use the Figma guide for Figma style names and tokens rather than guessing from a screenshot.