Является ли react-router-relay несовместимым с шаблоном Relay?

Я использую react-router-relay в проекте. Дизайн кажется мне неправильным, учитывая, что каждый компонент в основном заканчивается фрагментом, имеющим то же имя, что и корневой запрос. Разве каждый компонент не должен иметь уникально названные фрагменты любого произвольного типа в корневом запросе? Возможно ли это с помощью этого пакета или мое мышление здесь ошибочно?

Изменить: Возможно, мой вопрос был немного расплывчатым. Моя проблема в том, что есть по существу два правила для атрибута запросов, определенного react-router-relay, которые применяют то, что мне кажется странным шаблоном проектирования. Вот эти два правила:

  1. Каждый запрос может углубляться только на «один уровень».
  2. Каждый запрос должен сопоставляться с фрагментом с идентичным именем в компоненте, который его использует.

Это оставляет вам сценарий, в котором вы либо:

  1. Используйте один и тот же запрос «просмотрщика» для каждого компонента и определите дополнительный фрагмент «просмотрщика» для каждого компонента. Все эти фрагменты будут определять разные требования к данным, несмотря на то, что они имеют одно и то же имя, что кажется очень запутанным.
  2. Вы создаете уникальные имена фрагментов для разных компонентов, а затем повторяете один и тот же корневой запрос с разными именами в зависимости от типа данных, которые вы хотите получить, что кажется совершенно глупым.

person Dustin Phipps    schedule 16.07.2016    source источник


Ответы (1)


Хороший вопрос. Когда вы имеете дело с Relay, вы правильно думаете, что каждый компонент должен иметь свой собственный фрагмент, чтобы сам запрос точно отображал данные, необходимые для этого конкретного компонента. Называть фрагменты можно как угодно, но тип не может быть произвольным. Это должен быть объявленный тип под объектом Root Query (или любым другим полем, к которому вы добавляете фрагмент). В противном случае фрагмент выдаст ошибку о том, что вы не можете запросить этот тип в запросе или поле.

Например:

var componentOneFragment = Relay.QL`
    fragment on User {
        name
    }
`;

Здесь следует отметить, что вам не нужно иметь имя для таких фрагментов, как fragment userFragment on User { ... }. Это даст вам больше гибкости при динамическом обращении к фрагментам компонентов из запросов Relay в вашем маршрутизаторе путем объявления ${Component.getFragment(componentOneFragment)}. Надеюсь это поможет!

ИЗМЕНИТЬ:

Используйте один и тот же запрос «просмотрщика» для каждого компонента и определите дополнительный фрагмент «просмотрщика» для каждого компонента. Все эти фрагменты будут определять разные требования к данным, несмотря на то, что они имеют одно и то же имя, что кажется очень запутанным.

Хотя тот факт, что одинаковые имена фрагментов могут показаться запутанными, это лучший способ думать о вещах. Каждый компонент действительно имеет разные требования к данным, поэтому, естественно, их контейнеры Relay будут иметь разные фрагменты, но все же с одним и тем же именем фрагмента.

Этот фрагмент может быть включен в один из ваших контейнеров Relay, которому нужны данные User:

const WidgetList = Relay.createContainer(/* ... */, {
  initialVariables: {
    color: null,
    size: null,
    limit: null
  },

  fragments: {
    viewer: () => Relay.QL`
      fragment on User {
        widgets(color: $color, size: $size, first: $limit) {
          edges {
            node {
              name,
            },
          },
        },
      }
    `
  }
});

Хотя этот фрагмент (с тем же именем) может быть включен в другой контейнер Relay, которому нужны данные виджета:

const ActionsList = Relay.createContainer(/* ... */, {
  initialVariables: {
    input: null
  },

  fragments: {
    viewer: () => Relay.QL`
      fragment on Widget {
        actions(input: $input) {
          edges {
            node {
              name,
            },
          },
        },
      }
    `
  }
});

Оба они могут использоваться динамически (т. е. $Component.getFragment('viewer')) в одном и том же запросе GraphQL, если оба типа User и Widget относятся к объекту Root Query.

person vince    schedule 17.07.2016
comment
Спасибо за ваш ответ! Я понимаю, что запросы и фрагменты должны иметь смысл в контексте данной схемы GraphQL. Если вы посмотрите на редактирование, и я ответил на свой вопрос, я думаю, это может немного прояснить ситуацию. - person Dustin Phipps; 17.07.2016
comment
Я все еще не совсем понимаю, почему это лучший способ думать о вещах. Кажется, это не похоже на примеры ванильного реле, которые я видел, и я чувствую, что это делает фрагменты более запутанными. Если у вас есть время объяснить, я был бы очень признателен. - person Dustin Phipps; 17.07.2016
comment
Думайте о фрагментах как о строительных блоках запросов GraphQL. Имея это в виду, большую часть времени вы будете переписывать заголовки запросов всякий раз, когда вам нужны различные подвыборки данных. Или, если вы хотите запросить у Viewer другой тип данных, которые требуются другому компоненту, вы можете сделать это без необходимости переписывать заголовки запроса. С точки зрения организации кода, ваша DOM не только разделена на компоненты, но и ваши запросы GraphQL также будут разделены на компоненты в зависимости от требований к данным каждого компонента, поэтому вы точно знаете, какие данные принадлежат какому компоненту. - person vince; 17.07.2016