👩‍💻 Проектирование таблицы в React: SOLID, IoC и Render Props

В админке типового приложения таблицы встречаются на каждом шагу: пользователи, товары, заказы, подписки. Дизайн у них обычно единообразный — различаются только данные, заголовки и возможные действия в ячейках.

Проблема:
Если делать отдельный компонент под каждую сущность (UsersTable, ProductsTable), получим дублирование кода. Если запихать всю логику в один компонент — он превратится в монстра с кучей if-else.

Решение:
Делаем единную таблицу, но гибкую. Вместо хардкода данных и столбцов, выносим рендеринг наружу.

Какие техники применяем?
✔️ Render Props – Передаём renderRow и renderHeader как пропсы. Внутри Table только разметка, логика рендеринга — снаружи.

✔️ Принцип открытости/закрытости – Если для товаров нужна иконка валюты, а для пользователей — аватарка, не лезем внутрь Table, а просто рисуем нужное в переданной функции.

✔️ Dependency Injection – Зависимости (рендер-функции) приходят через пропсы. Можно подставить любую логику без изменений самого компонента.

✔️ Инверсия управления (IoC) – Table не знает, что в нём будет. Управление содержимым — у родителя.

✔️ Паттерн "Стратегия" – renderRow и renderHeader — это стратегии отображения. Подменяем их под задачу.

Итог:
Одна таблица на все случаи, без дублирования, с возможностью кастомизации под любую сущность.

Если тема интересна, сделаю серию постов про другие типовые компоненты: модалки, фильтры, карточки. Как вам идея?

#react #solid #patterns

👩‍💻 Разработка UI Kit: создание компонента Button

UI Kit представляет собой систематизированную коллекцию интерфейсных компонентов, которая служит фундаментом для разработки приложений. В современных проектах наличие продуманного UI Kit перешло из категории рекомендаций в обязательное требование по нескольким ключевым причинам.

1️⃣ Во-первых, UI Kit обеспечивает визуальную и функциональную согласованность интерфейса. Когда десятки или сотни экранов используют одни и те же компоненты
2️⃣ Во-вторых, разработка ускоряется в разы — вместо создания элементов с нуля, команда использует готовые решения.
3️⃣ В-третьих, значительно упрощается поддержка и масштабирование: изменения в дизайн-системе вносятся в одном месте, а применяются во всём проекте.

[Картинка 1: Пример Storybook]

UI Kit — это не просто коллекция кнопок и полей ввода. Это комплексная система, включающая:
- Базовые компоненты интерфейса (кнопки, формы, переключатели)
- Типографику и иерархию текста
- Цветовую палитру с семантическим значением цветов
- Систему отступов и размеров
- Состояния элементов (активное, неактивное, hover, focus)

[Картинка 2 и 3: Дизайн в Figma]

🛡 Основные принципы разработки компонентов UI Kit
При создании компонентов для UI Kit необходимо придерживаться нескольких фундаментальных принципов

1. Семантическая корректность
Каждый компонент должен максимально точно отражать свою суть на уровне HTML-разметки. Кнопка — это <button> или <input type="button">, ссылка — <a>, поле ввода — <input> или <textarea>. Это важно не только для доступности (accessibility), но и для правильной работы в различных контекстах (например, в формах или при навигации).

2. Полнота свойств
Компонент должен поддерживать все стандартные HTML-атрибуты соответствующего элемента. Для кнопки это включает type (button, submit, reset), disabled, autofocus и другие.

3. Управляемость извне
Компонент не должен содержать внутреннюю логику состояния (где это возможно). Все состояния (активное, неактивное, загружающееся) должны управляться через пропсы. Это делает компонент предсказуемым и легко интегрируемым в любую архитектуру.

4. Принцип открытости/закрытости
Компонент должен быть закрыт для модификаций (его базовое поведение нельзя изменить), но открыт для расширения. На практике это означает:
- Возможность добавления классов через className
- Возможность передачи произвольных атрибутов
- Гибкость в контенте через children

5. Единый источник правды
Изменение компонента в UI Kit должно автоматически отражаться во всех местах его использования. Это требует тщательного проектирования API компонента на этапе создания, чтобы избежать необходимости "ветвления" логики в будущем.

🔒 Архитектура UI Kit в проекте
Оптимальная структура для UI Kit в проекте выглядит следующим образом:

src/
  ui/
    Button/
      Button.tsx            # React-компонент
      Button.stories.tsx    # Документация в Storybook
      Button.test.tsx       # Тесты компонента
      Button.module.css     # Стили компонента
    Input/                 # Аналогичная структура для других компонентов
    ...
  styles/
    variables.css          # CSS-переменные (цвета, отступы, шрифты)
    typography.css         # Типографика
    animations.css         # Анимации
    global.css             # Глобальные стили

🖥 Реализация компонента Button для UI Kit
Перед разработкой тщательно изучаем макеты и выделяем все варианты кнопок: Варианты по стилю, Размеры, Состояния, Дополнительные требования (иконки, текст).

[Картинка 4: Компонент Button]

При стилизации используем CSS-переменные из дизайн-системы, Для каждого варианта прописываем цвета для всех состояний.

[Картинка 5: CSS-переменные]

Создаем подробные TypeScript-интерфейсы: Объединение с нативными атрибутами button и a, Поддержка всех стандартных HTML-атрибутов, Четкое разделение кастомных и стандартных пропсов

[Картинка 6: Типизация кнопки]

Далее создаем сторисы для всех вариантов: Основной вид, Все состояния, Примеры с иконками, Вариант как ссылки

#ui #storybook #button #react