До сих пор вы видели, как:
- Relay позволяет вам сказать, какие данные вам нужны с помощью GraphQL в части 1
- Relay получает данные с сервера в части 2
- Реле синхронизирует изменения обратно на сервер в части 3
Теперь давайте посмотрим, как все части работают вместе.
Предостережение: это только приблизительное значение.
В мультфильмах до сих пор масштаб диаграмм был 1: 1… каждая стрелка (в значительной степени) представляла один вызов функции.
Для этих диаграмм масштаб ближе к 1: 100. Это потому, что Relay так много делает для вас.
Флюс - это узор. Реле - это каркас. Flux просто дает вам рекомендации о том, как структурировать ваше приложение. Реле дает вам конкретную функциональность. И много всего.
Это означает, что количество различных частей в системе резко возросло.
Из диаграмм может показаться, что реализация чего-то с помощью Relay требует гораздо больше работы. По правде говоря, эти дополнительные персонажи сделают за вас много работы. Они несут ответственность за магию.
На самом деле вам не нужно знать все детали того, чем они занимаются. На самом деле, есть лишь небольшое количество деталей, о которых вам даже нужно знать.
Но самое интересное - открывать вещи и смотреть, как они работают! Итак, я попытаюсь дать вам приблизительное представление о внутренней работе Relay.
Хор персонажей
Даже если исключить некоторых из менее значительных участников, их все еще есть. В уме я делю их на 4 группы.
Пользовательский интерфейс
Пользовательский интерфейс берет данные из системы и делает их понятными для пользователя. Это также дает пользователю возможность изменить эти данные. Он принимает вводимые пользователем данные и превращает их в то, что понимает система.
Части пользовательского интерфейса:
Корневой контейнер. Подобно корневому компоненту в Redux, корневой контейнер является генеральным директором. Он выбирает компонент верхнего уровня для использования на странице. Он также сообщает приложению, где на графике начать запрос. Но после этого все в порядке.
Контейнеры - Контейнер похож на менеджера проекта для компонента. В нем есть список всех данных, необходимых компоненту для работы. Контейнер находится на вершине получения данных от остальной системы. Это позволяет компоненту сосредоточиться на своей работе.
Компоненты. Компонент в Relay практически такой же, как и в Flux. Это ведущий. Он просто знает, как форматировать данные для вывода, понятного людям (через HTML).
Relay Renderer. В некотором смысле Relay Renderer похож на привязку уровня представления из Redux. Как и ИТ-отдел, он подключает контейнер к магазину.
Мутации - вы видели мутации в части 3. Они похожи на создателей действий в Flux, но делают больше. Они предоставляют схемы системы мутаций для различных пользовательских изменений.
Хранилище данных
Хранением данных занимается магазин. Хотя здесь я представляю его как одного персонажа, здесь задействовано много разных объектов.
Пользовательский интерфейс обращается к нему всякий раз, когда ему нужны данные. Он работает с системами запросов и мутаций, чтобы убедиться, что в нем есть данные, необходимые пользовательскому интерфейсу. В магазине также есть система уведомлений. Каждый компонент получает индивидуальные обновления при изменении данных, которые он использует. Магазин обрабатывает все детали подключения этих уведомлений, поэтому вам не нужно об этом думать.
Системы запросов / мутаций
Системы запросов и мутаций подготавливают запросы. Они также отслеживают, какие запросы были отправлены и какие данные должны поступить для выполнения запроса. Вы встречались с ними в части 2 и части 3.
Облако
Два символа находятся по обе стороны облака: сервер с одной стороны и сетевой уровень (который находится на клиенте) с другой.
Сервер. Как вы видели в части 1, сервер GraphQL похож на библиотекаря. Это не библиотека; на самом деле он не хранит информацию. Вы сообщаете серверу GraphQL, какая информация вам нужна, и он выясняет, где в стеке найти эту информацию для вас.
Сетевой уровень. Сетевой уровень управляет всем обменом данными с сервером. Это как оператор в Матрице. Он отвечает за получение запросов в облако и обеспечение того, чтобы ответы поступали из облака. Если ответ не выходит из облака должным образом, оператор повторит попытку дважды, прежде чем вынуть вилку из розетки. Он также обрабатывает ошибки.
Первый рендер
Посмотрим, что произойдет при первой загрузке вашего приложения.
Шаг 1. Запуск процесса
Когда страница загружена, React начинает рендеринг. Первое, что он достает, - это корневой контейнер. Корневой контейнер передает ответственность Relay Renderer.
Relay Renderer отвечает за то, чтобы данные были доступны пользовательскому интерфейсу. Но поскольку приложение не смонтировано, оно знает, что эти данные недоступны. Он сообщает магазину, что нужно начать заполнение кеша.
Шаг 2. Подготовка кеша
Магазин должен знать, какие данные получить для кеша. Relay Renderer определяет начальную точку запроса (корень запроса) и передает ее в магазин. Это также дает магазину обратный вызов.
Магазин передает их системе запросов. Затем система запросов работает с магазином, чтобы выяснить, какие данные уже находятся в кеше. Мы рассмотрели это во части 2.
Шаг 3. Создание запроса
Система запросов строит запрос.
Я не показывал это во части 2, но здесь система запросов обращается к контейнерам. Он спрашивает их, какие данные им нужны. Каждый контейнер передает фрагмент запроса, в котором указываются данные, необходимые его компоненту.
Система запросов собирает полный запрос из всех этих фрагментов.
Шаг 4. Обрезка запроса и постановка его в очередь
Как мы видели в части 2, система запросов удаляет ожидающие запросы из запроса. Затем он добавляет запрос в очередь запросов сетевого уровня для отправки (а также добавляет его в свой собственный список ожидающих запросов).
Примечание: здесь все становится немного асинхронным. У меня нет хорошего способа показать это на диаграммах.
Система запросов на данный момент закончена. Он ставит в очередь сообщение для Relay Renderer с состоянием готовности. Но сначала сетевой уровень должен выполнять свою работу ...
Шаг 5: Отправка запроса на сервер GraphQL
Сетевой уровень забирает очередь запросов, оставленных ему системой отслеживания запросов. Он отправляет запросы на сервер GraphQL.
Сетевому уровню больше нечего делать, пока сервер не ответит. Это позволяет остальной системе делать свое дело, пока она ждет.
Сообщение, которое система запросов поместила в очередь, отправлено. Relay Renderer получает состояние готовности.
Шаг 6. Получение данных и запись их в кеш.
Сетевой уровень получает ответ от сервера GraphQL. Преобразует ответ в JSON. Затем система запросов забирает его и передает в магазин. Магазин добавляет его в локальный кеш.
Шаг 7. Уведомление средства визуализации
Как только данные записываются в кэш, система запросов уведомляется. Он отправляет сообщение Relay Renderer с новым состоянием готовности, позволяя Renderer знать, что кеш загружен и готов к работе.
Затем Relay Renderer подготовит объект, который контейнеры могут использовать для получения данных из хранилища. Он вызывает setState (), передавая этот объект контейнерам.
Шаг 8: Получение данных из магазина в пользовательский интерфейс
Используя объект, который передал Relay Renderer, контейнер настроит «преобразователь». Он будет использовать преобразователь для получения данных из магазина.
Примечание. Это выполняется автоматически в реализации componentWillMount () прототипа контейнера.
Во время этого процесса магазин также настраивает наблюдателей. Эти наблюдатели будут уведомлять резолвер, который будет уведомлять контейнер, когда эти данные изменились.
Теперь, когда в контейнере есть данные, он вызывает setState (), чтобы передать их компоненту.
Вот как я думаю обо всех частях Relay. Надеюсь, это поможет!
Это помогло? Если да, то щелчок по значку ♥ очень ценится… он помогает другим людям его найти!
