Роль QueryRenderer в современном реле?

Итак, сначала немного фона. Я родной разработчик iOS/Android, который сейчас начинает мой первый проект React Native. Он поставляется со всеми преимуществами и болями Javascript, но мне это очень нравится:-) Я решил также попробовать свои силы в GraphQL в первый раз.

Будучи новичком в среде React вообще, у меня также нет никаких предварительных знаний об Relay, но выбрал его по рекомендации друзей в моем сообществе автозагрузки и моих коллегах по веб-разработчикам. Я также был предупрежден о некоторой крутой кривой обучения, но решил пойти в любом случае - я уже сражаюсь в тяжелой битве с JS и версией новой мобильной платформы 0.xx, так что, черт возьми, да?:-) Мне удалось правильно настроить проект и перенести его на мой GQL-сервер с помощью QueryRenderer, что было большим облегчением: -)

Итак, на вопросы

Мне сложно определить соотношение между контейнером и компонентом и состав контейнера в целом. Чтение документов по составу помогло, но я все еще сомневаюсь в роли QueryRenderer

  • QueryRenderer говорят, что документы являются корневым контейнером для каждого дерева ретрансляции. Означает ли это, что для нашего корня в нашем приложении должен быть QueryRenderer? Или в корне каждого пути навигации (т.е. Вкладки в нашем приложении)? Или только для каждого компонента контейнера (в отличие от презентационных/немых/чистых компонентов, React wise)? Заметьте, что я не ищу мнения, но аргументы за лучшую практику: -)
  • Может ли FragmentContainer (или любой другой контейнер, если на то пошло) работать без QueryRenderer в родительском компоненте?
  • Как связать QueryRenderer с дочерними контейнерами? Получает ли она сумму всех данных, которые нужны дочерним контейнерам, а затем дочерние контейнеры, считанные из кеша, или? Если это так, Ive неправильно понимает плюсы Relay - у нас создается впечатление, что каждый компонент может извлекать данные независимо от всех других компонентов и что каждый компонент ничего не знает о требованиях к данным других компонентов (включая родительские/дочерние компоненты). Я думаю, что это предположение также меня смущает о QueryRenderer и необходимости в контейнере "Root".
  • Если QueryRenderer является корневым контейнером корня/родительского корня в дереве ретрансляции, каким образом он должен визуализировать компоненты представления на основе его запроса? И почему у него должен быть запрос? Когда и для чего следует использовать QueryRenderer?

Любая помощь очень ценится: -)

Ответы

Ответ 1

Итак, после работы с нашим приложением, я думал, что вернусь к сообщению о наших мыслях и опытах до сих пор в надежде, что это поможет кому-то.

Основываясь на замечательном посте @Peter Suwara, мы пришли к аналогичной стратегии изначально

  • Создайте дерево корневого/родительского дерева
  • Для каждого экрана в дереве есть QueryRenderer в качестве корня для всех презентационных/немых компонентов, содержащихся
  • Использование фрагментов для объявления зависимостей данных внутри подкомпонентов

Как мы уже говорили в комментариях ниже его ответа, этот подход не всегда может быть лучшим. После дальнейшего обсуждения внутри мы пришли к выводу, что слишком много случаев, когда это может не иметь смысла в конце концов по нескольким причинам:

  • Если вы извлекаете данные для каждой загрузки экрана, вы часто будете иметь больше обращений, чем необходимо. Вы хотите принять во внимание приложение-поток и получить столько данных, сколько необходимо для маршрута и его детей.
  • Кроме того, если вы извлекаете все данные для дочерних компонентов экрана на одном и том же QueryRenderer, иногда вы можете получать данные, которые никогда не будут отображаться для пользователя (т.е. подробности для подробного представления, которое редко отображается, или аналогичные случаи).

После еще нескольких размышлений и обсуждения мы придумали это правило для того, чтобы создать новый корень QueryRenderer дерева ретрансляции:

Создайте новый QueryRenderer для всякой необходимости новой стратегии обработки ошибок

Это происходило по самой практической причине, что это единственный шанс, с которым вы столкнулись с ошибками/загрузкой данных, но это также имело смысл для нас в способе потока пользователей и композиции, как обычно сталкиваются две вещи - вы хотите новый способ обработки сетевых ошибок при достижении нового "потока" /части вашего приложения. Может быть, какие-то более умные головы в Facebook думали об этом перед нами?: -)

Как и во всех эмпирических правилах, это просто - руководство, а не правило, и у него есть исключения, конечно. Однако, кажется, это имеет смысл для нас внутренне - по крайней мере на данный момент.

Любая и всякая обратная связь по этим мыслям очень приветствуется, так как я думаю, что официальные документы являются слабыми, если не сказать больше, поэтому обсуждение сообщества - это все, что у нас есть, пока документы и общие шаблоны не будут урегулированы со временем.

Ответ 2

Спасибо, что подняли эту тему. Я тоже только что попал в Relay с ReactNative и с некоторыми захватывающими результатами.

Во-первых, я удивлен, насколько легко было привнести компоненты интерфейса, отражающие базы данных GraphQL, на экран. После первоначальных накладных расходов на изучение основ JavaScript и ответного канала, Relay стал фантастическим способом представления данных.

Что касается лучших практик, я не могу точно сказать, как представить свои QueryRenderer и objectContainer, однако я могу описать наш способ представления данных.

Во-первых, мы создаем стек реакции и вкладки для реагирования. Внутри каждого основного экрана мы запускаем QueryRenderer. Затем в пределах этого QueryRenderer для каждого конкретного компонента пользовательского интерфейса мы разделяем на фрагментContainer.

  • Навигационный поток (интерактивная навигация, навигаторы на стеке/вкладке)
  • Интерфейс экрана (QueryRenderer)
  • Виджет/Компонент (fragContainer)

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

В идеале я хотел бы попробовать QueryRenderer в верхней части Navigator, однако я еще не совсем понял, как и если это будет работать, поскольку навигаторы не отвечают на функцию render(), которая требуется QueryRenderer.

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