STDF Documentation

STDF is a mobile web component library built on Svelte 5, Tailwind CSS v4, and TypeScript. It is designed to be Simple, Tiny, Design-focused, and Fast.

Key features include:

• No runtime or virtual DOM: Optimized for web performance.
• Rich API: Easily configurable component styles and animation parameters.
• Theming: Supports dark mode and multiple custom themes.
• Internationalization: Built-in support for over 60 language packages.
• Zero third-party dependencies: Reduces security risks and version conflicts.
• On-demand imports: Supports tree-shaking to reduce bundle sizes.
• Tooling: Includes a scaffolding tool for rapid project creation, an SVG merging plugin, and an IDE plugin for component API visibility.

STDF is a mobile web component library built with Svelte 5, Tailwind CSS v4, and TypeScript. It is designed to be Simple, Tiny, Design-focused, and Fast.

Key features include:

• Performance: No runtime overhead and no virtual DOM.
• Customization: Rich API for component styling, configurable animation parameters, and support for multiple themes (including dark mode).
• Zero Dependencies: No third-party dependencies, reducing security risks and version conflicts.
• Modern Tooling: Supports on-demand imports for smaller bundles, an SVG fusion plugin, and an IDE plugin for quick API inspection.
• Internationalization: Built-in support for over 60 language packages.
• Compatibility: Works with Tailwind-compatible libraries like UnoCSS.

STDF is a mobile-focused UI component library built on top of Svelte and Tailwind CSS.

Its core design philosophy focuses on:

• Simplicity & Lightweight: Aiming for a small footprint suitable for mobile environments.
• Design-Friendly: Providing APIs that are flexible enough for business requirements without being overly complex.
• High Reusability: Avoiding overly personalized UI styles to ensure components can be reused across different projects.
• Developer Experience: Leveraging the reactive capabilities of Svelte and the utility-first approach of Tailwind CSS to provide a comfortable development workflow.

The Cell component supports three types of Snippets to allow custom rendering in specific areas:

• leftChild: Renders content at the far left of the Cell (e.g., custom images or icons).
• rightChild: Renders content at the far right of the Cell.
• detailChild: Renders detailed content in the right-side area of the Cell.

Use these snippets when the default icon or text layout does not meet your design requirements.

<Cell>
  <div slot="leftChild">Custom Left Content</div>
  <div slot="detailChild">Custom Detail Content</div>
</Cell>

The Card component provides three optional preset areas for organizing content:

• header: The top area, typically used for titles, action buttons, etc.
• children: The main body area for the primary content.
• footer: The bottom area, typically used for action buttons or statistics.

These areas are optional and can be combined flexibly based on your requirements.

In STDF, both BottomSheet and Popup are floating UI elements used for secondary operations, but they serve different conceptual purposes:

• Popup (Layer concept): Best for simple interactions. It is "style-heavy, logic-light." You can customize its position, size, transition animations, direction, and style. By default, clicking the mask (overlay) closes it.
• BottomSheet (Window concept): Best for complex interactions. It is "logic-heavy, style-light." It always emerges from the bottom and features a dedicated header area that can be customized. It supports window-like interactions such as sliding to close or navigating back. By default, clicking the mask does not close it.

In STDF, the Alert component is a card-style notification designed for richer content presentation (titles, icons, or actions) where readability is key. It sits in a hierarchy of feedback components:

• Toast: Lightweight and non-blocking; used for short status feedback for quick actions.
• Alert: Card-style; used for richer notices requiring more visual weight than a toast.
• Modal: High awareness with minimal interaction (e.g., a single acknowledgment).
• Dialog: High awareness for decision-making (e.g., primary/secondary actions for risky flows).

Use Alert when you need to provide more context than a simple status message but don't want to interrupt the user's workflow as heavily as a Modal or Dialog would.