Philosophy

Aksara UI provides atomic components for building your own interfaces. The goal is flexibility. You choose how the pieces fit your product instead of adapting your product to a pre-built, all-in-one component.

Building blocks, not finished screensCopy Anchor Link

An atomic component has a focused responsibility. A Button triggers an action. An Input accepts text. A Dialog provides the parts for a modal interaction.

These components do not decide your page layout, business rules or workflow. Your app decides what a form submits, when a dialog closes after a request, and which actions a user can take.

Atomic does not mean unstyled. Components include default styles, design tokens and interaction behaviour. You start with a working component and adapt it to your screen.

Compose the parts you needCopy Anchor Link

Components with several responsibilities expose separate parts. With Dialog, you choose the trigger, title, body and footer. You can use the standard header or compose a title and description yourself.

The footer does not prescribe a set of buttons or their order. Put the actions your task needs inside it and arrange them with your own layout classes. The Dialog examples show these choices in context.

This approach can require more JSX than a single component with a large configuration object. In return, the structure stays visible in your code, and you can change one part without replacing the whole interaction.

Customise through explicit APIsCopy Anchor Link

Use the level of customisation that fits the task.

• Use props for supported sizes, variants and states.
• Use className and token utilities to adjust layout and styling.
• Use slots for icons, actions and other content.
• Use render, where supported, to supply your own element, such as a router link or a custom trigger.
• Use controlled state and event handlers to connect the interaction to your app's data.

Each component documents which options it supports and which element receives your classes or ref. Not every part accepts render. See Usage for the common patterns and the component's API table for its specific options.

Keep shared styles, own the experienceCopy Anchor Link

Use the design tokens for shared colours, typography, spacing and radius. They keep your custom layouts consistent with the components and let them follow your app's theme.

Build product-specific components from these pieces. Your team might create an invite form, a report picker or a confirmation dialog with its own content and request handling. Reuse those combinations across your app without putting product rules into every individual control.

Preserve accessibility when customisingCopy Anchor Link

Flexibility comes with responsibilities. Components provide keyboard and focus behaviour, but your app must supply meaningful labels, error messages and a logical reading order.

When you replace an element or rearrange content, preserve its semantics and interaction. Avoid nested buttons and links, keep focus indicators visible, and follow the accessibility guidance on each component page.