По умолчанию клиент Apollo использует fetchPolicy
из cache-first
.Это означает, что если результат запроса уже находится в кэше, он будет извлечен оттуда и сетевой запрос не будет выполнен.Это позволяет вам использовать один и тот же запрос для нескольких Query
компонентов, не беспокоясь о том, чтобы снова и снова повторять один и тот же запрос к вашему серверу.
Вы можете указать fetchPolicy
для определенного компонента Query, еслиВы хотите переопределить это поведение по умолчанию - например, может быть, вы хотите всегда получать новые данные с сервера, в этом случае вы будете использовать network-only
или, возможно, cache-and-network
.См. в документах для получения более подробной информации.
ПРИМЕЧАНИЕ. Обычная "ошибка" заключается в том, что кэш использует поле id
(или _id
) для нормализации кэшированных результатов.Это означает, что ваши запросы должны включать поле id
(или предоставлять пользовательскую реализацию dataIdFromObject
), чтобы увидеть ожидаемое поведение.См. Эту страницу для получения дополнительной информации.
С точки зрения поддержания сухости вещей принято хранить ваши запросы в одном или нескольких отдельных модулях, а затем импортировать их по мере необходимости.Таким образом, вы можете получить файл queries.js
, подобный следующему:
import gql from 'graphql-tag'
export const USER_QUERY = gql`
query User {
user {
_id,
email
}
}
`
graphql-tag
поставляется с загрузчиком, который позволяет импортировать запросы непосредственно из файлов .graphql / .gql, если вы используете Webpack.Посмотрите рецепт здесь .Есть также плагин Babel для того, чтобы эффективно делать то же самое (зацените здесь ).Любой из этих подходов должен уменьшить избыточность в вашем коде.
РЕДАКТИРОВАТЬ: Как указано в ответе @ camba1, фрагменты могут также использоваться для СУШКИ ваших запросов:
query User {
user {
...userFields
}
}
fragment userFields on User {
_id,
email,
}