Data Binding

Rokkit is built around one principle: your data should drive your UI, not the other way around. Every selection component — List, Select, Tree — works with your data as-is via field mapping, not by forcing you to reshape it.

Overview

Most component libraries require your data to match a specific shape. A Select needs { label, value }, a Tree needs { name, children }. Every component has its own convention, so you write adapters everywhere.

The Rokkit Approach

Instead, every Rokkit component accepts a fields prop that maps your keys to the component's semantic fields. Your { name, id, nested } data works directly — no transformation, no adapter layer.

Field Mapping

The fields prop is Rokkit's core concept. Instead of reshaping your data to match component contracts, you tell components which fields in your data map to which roles.

The Problem

Most UI libraries force you to transform your API data into their expected shape. If your API returns { name, id } but the component expects { label, key }, you write adapter code everywhere.

The Rokkit Way

Pass a fields object that maps component roles to your data's property names:

Standard Field Roles

Default Mapping

When no fields prop is provided, Rokkit uses the field names directly. So if your data already has text and value properties, no mapping is needed.

Primitive Arrays

For arrays of strings or numbers, each item is used as both text and value automatically:

Nested Data

Map the children field for hierarchical data. Groups with children render as collapsible sections in List and Tree, or as option groups in Select and Menu.

Data Sources

Coming soon.