vercel-composition-patterns

vercel-composition-patterns — скилл Vercel для проектирования и рефакторинга гибких React-компонентов и API библиотек. Он нужен в тех случаях, когда компонент начинает обрастать boolean-пропами, когда требуется построить reusable component library, спроектировать расширяемый API или пересмотреть архитектуру компонентов. В триггерах исходника прямо названы compound components, render props, context providers и component architecture; это не общий курс по React и не набор готовых виджетов. Главная рекомендация — не кодировать множество режимов через цепочку boolean props, а собирать поведение композицией. В compiled guide четыре группы правил с приоритетами. Component Architecture имеет высокий приоритет и включает отказ от boolean props и compound components с общим context. State Management имеет средний приоритет: реализация состояния должна быть скрыта в provider, общий интерфейс состояния, действий и метаданных должен оставаться явным, а состояние при необходимости поднимается в provider, чтобы соседние элементы могли его использовать. Implementation Patterns также имеют средний приоритет: вместо неявных boolean-режимов предлагаются явные variant-компоненты, а children предпочтительнее renderX-пропов как механизм композиции. В практическом рефакторинге это означает сначала найти пропы, которые переключают независимые варианты поведения, и проверить, не смешаны ли в одном компоненте визуальная оболочка, состояние и детали реализации. Затем публичный API можно разложить на составные части: provider владеет управлением состоянием, дочерние части получают согласованный контракт через context, а варианты интерфейса выражаются отдельными компонентами или структурой children. Такой подход делает границы API видимыми и позволяет добавлять комбинации без бесконечного расширения списка флагов. Если состояние должно быть доступно нескольким соседним частям, его следует поднять до общего provider, но не заставлять каждую часть знать, как именно состояние хранится. Отдельный раздел посвящён React 19 и должен применяться только в проектах на React 19 или новее. Для этой ветки исходник указывает не использовать forwardRef и предпочитать use() вместо useContext(). Если проект работает на React 18 или более ранней версии, React 19-раздел пропускается; это ограничение не нужно компенсировать ручным копированием нового API в старый runtime. Скилл полезен при миграции компонента с пропами вида isCompact, hasHeader и renderItem к compound API, при создании компонентов меню, вкладок, модальных окон или полей формы с несколькими составными частями, а также при ревью публичного React-интерфейса перед его выпуском в библиотеку. Он задаёт архитектурные эвристики и форму API, но не выбирает за проект конкретный state manager, не обещает автоматическую оптимизацию рендера и не заменяет проверку совместимости с фактической версией React. Подробности следует брать из отдельных rule-файлов репозитория: исходник перечисляет правила и даёт навигацию, а не утверждает, что любой компонент обязан использовать один шаблон.