Learn
Learn is the concept layer. Each page teaches one rule that explains many components at once, so that you can predict what BeeUI will do rather than discovering it per component.
It is deliberately not the other two layers. Start gets one thing running. Guides give the shortest correct path to a specific outcome. Reference holds exact values, props and commands. Learn sits between them and answers why the API looks like this.
Every page follows the same shape: the concept in one sentence, why it exists, a diagram or minimal example, the rules that always hold, what that means for your code, the misconception that costs people a day, and where to go next.
Prerequisites: none — this is an index page; each linked Learn page states its own prerequisites, and the suggested reading order below assumes no prior BeeUI knowledge.
Start here
Section titled “Start here”| Page | The one sentence |
|---|---|
| Foundations | BeeUI is a mobile-first React Native + TypeScript UI system whose public product is component behavior contracts and semantic tokens — not an application framework. |
| Ownership model | BeeUI owns component behavior, semantic tokens and the provider runtime; your application owns routing, data, domain state and product policy. |
How components are built
Section titled “How components are built”| Page | The one sentence |
|---|---|
| Composition model | A compound component is one root that owns state and context, plus named parts that read it. |
| State model | Components hold internal state only for the interaction they own; any value your product cares about is passed in and reported back. |
| Forms model | BeeUI renders invalid; it does not decide what invalid means. |
| Overlays & runtime ownership | Overlays are clients of two provider-owned runtimes — and those two runtimes nest differently. |
How BeeUI meets the real world
Section titled “How BeeUI meets the real world”| Page | The one sentence |
|---|---|
| Cross-platform model | Shared source means one API and one contract across Web, iOS and Android — never that evidence transfers between them. |
| Responsive model | BeeUI is compact-first: extra width is capability your layout opts into, not a different design. |
| Accessibility model | A component-level contract plus a deliberate hand-off to the platform — never a certification, and never a substitute for your composition. |
Suggested reading order
Section titled “Suggested reading order”If you are new, read Foundations and Ownership model first — every other page assumes that boundary. After that, follow whichever branch matches what you are building:
Foundations ─► Ownership model ─┬─► Composition ─► State ─┬─► Forms │ └─► Overlays & runtime └─► Cross-platform ─┬─► Responsive └─► AccessibilityRelated material elsewhere
Section titled “Related material elsewhere”These pages remain authoritative for their own topics, and the Learn pages link into them rather than restating them:
- Architecture & design principles — the condensed architectural summary.
- Theming — the semantic token contract in practice.
- Accessibility — the executable accessibility task guides.
- Compatibility — the machine-checked version and evidence contract.
- Responsive & mobile-first — the short task-level summary.
- Provider & safe area — provider setup with a verification checklist.
- Performance and Release & security — operational contracts.
For exact values, symbols, commands and compatibility data, go to Reference instead.