Catalog

Проведи ультра глубокий системный рефакторинг UI-кода в соответствие с правилами описанными ниже: ОСНОВНОЙ ПРИНЦИП Все визуальные стили компонента живут строго внутри компонента. Снаружи нельзя прокидывать стили, влияющие на внешний вид (`style`, `className` и аналоги). Снаружи управляем только: - семантическими пропсами (`variant`, `size`, `tone`, `state`, `disabled` и т.д.) - расположением в макете через компонент-обертку Wrapper, который имеет dir=row/column и padding/gap как props (`gap`, `padding`, `margin`, `flex`, `grid`, выравнивание, позиционирование) ЧТО СЧИТАТЬ ПЛОХОЙ ПРАКТИКОЙ - прокидывается `style` или `className` ради изменения внешнего вида (косметика) - стили частично внутри компонента, частично снаружи - внешний код (Wrapper компонент) переопределяет паддинги, цвета, бордеры, фоны, размеры, радиусы, тени и прочие визуальные свойства - компонент используется как заготовка, а финальный вид собирается снаружи - один и тот же стиль где-то захардкожен, а где-то пробрасывается пропсами КАКОЙ ПОДХОД СЧИТАТЬ ПРАВИЛЬНЫМ Компонент имеет чистый и понятный API. Разные визуальные режимы выражаются через явные пропсы: `variant`, `size`, `colorScheme`, `tone`, `fullWidth`, и т.п. ТВОЯ ЗАДАЧА Иди по файлам последовательно. Для каждого файла: 1. Найди места, где стили пробрасываются внутрь 2. Раздели их на: - внешний layout - и внутренний визуальный/косметический слой 3. Layout оставь снаружи через обертки (Wrapper компонент) 4. Визуальные стили перенеси внутрь компонента и реализуй его отдельно, как самостоятельный компонент 5. Удали `style` и прочие override-механизмы, в идеале вообще избавиться от всех вредных style/className пропсов и регулировать расположение (padding/gap/margin/тд) через дополнительный Wrapper компонент снаружи, это трейдофф на который мы готовы пойти ради чистой архитектуры и невозможности переопределить косметику компонента снаружи 6. Упрости API (пропсы компонента), если они расплывчатые, пропс не используется после рефакторинга, его можно чище объединить с другим пропсом 7. Даже если компонент используется один раз — вынеси его в `components/`, прям все компоненты плоско аккуратно кладем в одну папку `components/`, в страницах (Pages), экранах (Screen) и роутах (Routes) не должно быть локальных для страницы компонентов, страница собирается из `components/`. При последующем рефакторинге, проверяй есть ли уже реализованный компонент в `components/`, если да, то переиспользуй его, возможно расширив его функциональность, или наоборот переиспользуй ЧЕГО НЕ ДЕЛАТЬ - Не оставлять временные overrides (нигде) - Не вводить пропсы, зеркалящие CSS (`padding`, `background`, `borderRadius` и т.д.), все должно быть упрощено или выражено через отдельный вариант компонента - Не ломать существующее поведение, мы исключительно работаем с UI (косметикой) и приводим UI к системной аккуратной реализации через компонентный подход ПРИНЦИП ПРИНЯТИЯ РЕШЕНИЙ Если стиль описывает "как выглядит компонент" — он внутри. Если это только "размещение среди других элементов" — снаружи. ОЖИДАЕМЫЙ РЕЗУЛЬТАТ Код страниц/экранов должен стать: чище, предсказуемее, компонентнее, без вермишели из проброшенных стилей, без хардкода и override’ов, с четкой границей между layout и visual styling ФОРМАТ РАБОТЫ Открой первый файл. Орефактори его. Затем по каждому файлу: - что было плохо - что перенесено внутрь - какие пропсы добавлены/упрощены - что удалено из API компонента при переносе - почему стало чище Затем переходим к следующему файлу. В спорных случаях выбирай более строгий компонентный подход. никаких "временных" хвостов, все сразу должно быть реализовано по-уму Главная цель: убрать кашу и собрать дисциплинированную компонентную архитектуру.