Перейти к содержанию
Mercury
Русский
Дизайн книга
Меню
Русский

Reflect. От модели к представлению

Обычное представление получает свойства. Модель Hypergraph хранит состояние и задаёт действия. Reflect связывает их, оставляя бизнес-правила в модели.

Reflect 4.1.1 · Интерактивное упражнение

Открыть упражнение на всю страницу

Начните с видимого изменения

Введите имя, нажмите кнопку счётчика и проследите, как представление получает новые свойства. Затем выведите одну модель в двух независимых областях состояния. К концу курса вы сможете объяснить, откуда пришло значение, куда записывает обработчик и почему строка сохранила или потеряла локальное состояние.

Примеры используют @fiberfx/reflect 4.1.1, @fiberfx/hypergraph и @fiberfx/hyperscript 4.1.1. Упражнения работают в браузере: для чтения и экспериментов Node не нужен. Для локальной сборки и браузерных тестов применяется нативный mx в настроенном рабочем пространстве Mercury. Подготовка описана в главе первое приложение с mx.

Перед началом разберитесь с событиями и хранилищами, свойствами компонентов и разницей между событием ввода и готовым значением в главе поля и формы. Для изоляции состояния пригодится глава fork и scopeBind.

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

1–3. Связываем состояние и действия

  1. Reflect.1. Связываем представление: поле имени и счётчик, адаптер HTML-тега и повторное использование фабрики.
  2. Reflect.2. Вычисляем свойства: подпись из хранилищ и входных свойств; явное переопределение отменяет вычисление.
  3. Reflect.3. Разделяем области состояния: два независимых счётчика на одной модели и проверка неизменности глобального значения.

4–6. Собираем интерфейс

  1. Reflect.4. Сохраняем строки по ключам: перестановка строк без переноса состояния флажка к чужому элементу.
  2. Reflect.5. Выбираем представление: готовый результат, пустой экран, ошибка и явный запасной вариант.
  3. Reflect.6. Заменяем компоненты: выбор краткого или подробного вида из постоянного реестра; идентичность строки и дочернего компонента.

7–8. Наблюдаем и проверяем

  1. Reflect.7. Следим за временем жизни: обновление подписи, скрытие компонента и свойства, сохранённые для хуков монтирования и размонтирования.
  2. Reflect.8. Проверяем границу: браузерный регрессионный тест для двух областей, затем проверки отказов, идентичности и серверного рендеринга.

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

Граница опубликованного API

Пакет экспортирует reflect, createReflect, list, variant и fromTag. mapProps — поле конфигурации фабрик, а не шестая экспортируемая функция. Типы описывают привязки, источники и свойства, которые вызывающая сторона ещё должна передать.

Для настройки представлений курс использует обычные свойства компонентов. Дескрипторы ресурсов и их жизненного цикла, селекторы, именованные слоты и API пресетов в этой версии не поставляются. Неявного объединения классов и цепочек обработчиков нет. Используйте публичные свойства Mercury UI и классы приложения, а не приватные .mx-*.

Основание курса — ревизия 20dad1543358ab293c61b004a1f5f2577915798b. Официальные метаданные пакета 4.1.1 указывают опубликованную версию и её точные peer-зависимости. Примеры объясняют этот контракт; конкретному приложению всё равно нужны собственные тесты.