Что произошло

Стартовая боль знакома: Tailwind решает cascade и мёртвые стили, но визуальная часть живёт в непрозрачной строке без автодополнения и рефакторинга. Автор спросил: что если variant, color, size — обычные типизированные props, а за кадром — utilities через tailwind-variants и design tokens?

Следующий слой — формы. Паттерн RHF с Controller и render prop на 50-м поле утомляет. TextField с name="email" сам читает value, ошибки и blur/submit-логику через context-мост — без ручной проводки.

Дальше — оркестрация бизнес-UI:

• visibleWhen — поле описывает условие показа (customerType === business), без watch + useEffect на каждое правило.
• access на кнопке — invoice:update внутри компонента, а не permissions.includes в каждом экране.

Архитектурный поворот: две UI-библиотеки (MUI и Tailwind + Radix) с одинаковыми props оркестрации, но общим headless-движком (мост форм, видимость полей, RBAC). Стили сменяемы; «интеллект» приложения — в ядре.

Почему это важно

В enterprise-формах основная стоимость — не пиксели, а glue-код: связать поле с формой, валидацией, правами, условной видимостью. Typed visual API снижает класс ошибок в стилях; application-aware components — повторяющийся boilerplate на сотнях экранов.

Это не «ещё один UI-kit»: DashForge в alpha, но идея — вынести повторяющуюся оркестрацию в декларативные props, оставив Radix/React Aria для a11y.

На практике

1. Visual API — props-first поверх Tailwind; один escape hatch sx с tailwind-merge.
2. Поля — <TextField name="…" label="…" /> вместо Controller + error plumbing.
3. Условия — visibleWhen={{ field, equals }} вместо watch/effect.
4. Права — access="resource:action" на интерактивных узлах.
5. Оценка зрелости — alpha; смотреть @dashforge/tw и repo перед adoption в продакшен.

Итог

История — про смещение фокуса с «как стилизовать» на «как компонент участвует в приложении». Если устали от copy-paste проводки форм — имеет смысл посмотреть DashForge как эксперимент, не как готовую замену всему стеку.