В чем разница между «магазином и сетью» и «только сетью»?

Я прочитал документацию и до сих пор не понимаю разницы между политикой выборки «хранение и сеть» и «только сеть».

store-and-network: будет повторно использовать локально кэшированные данные и всегда будет отправлять сетевой запрос, независимо от того, отсутствовали какие-либо данные в локальном кэше или нет.

только для сети: не будет повторно использовать локально кэшированные данные и всегда будет отправлять сетевой запрос для получения запроса, игнорируя любые данные, которые могут быть локально кэшированы в Relay.

Я просто не могу понять, в чем смысл «магазина и сети». Он утверждает, что будет повторно использовать локально кэшированные данные ... но он ВСЕГДА извлекается из сети, так что именно ЧТО он может повторно использовать?

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


person Adam Wall    schedule 19.11.2020    source источник


Ответы (1)


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

Документы расширяют эту концепцию здесь: https://relay.dev/docs/en/a-guided-tour-of-relay#presence-of-data

Однако, резюмируя:

  1. Отсутствующие данные. Релейный мусор собирает данные в хранилище, когда обнаруживает, что определенный фрагмент данных больше нигде не обрабатывается. Это обрабатывается разными способами, но обычно коррелирует с монтированием/размонтированием компонентов, которые поддерживают (редактируют) ссылку на конкретный фрагмент или запрос. Как только Relay обнаруживает, что в хранилище нет активной ссылки на некоторые данные, он планирует эти данные для сборки мусора.

  2. Устаревшие данные. Данные могут быть устаревшими, но не запланированными для сборки мусора. Это тот случай, когда данные не отсутствуют (как в № 1), а просто нуждаются в обновлении — вероятно, после мутации. Еще есть ссылка на данные в хранилище через смонтированный компонент.

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

С другой стороны, политика извлечения из хранилища и сети чувствительна к наличию (или их отсутствию) или устареванию (или их отсутствию) данных в вашем магазине.

Он проверит, существуют ли в хранилище данные, необходимые для рендеринга конкретного компонента:

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

(b) если в какой-либо момент рендеринга дерева Relay встретит компонент с требованиями к данным, которых нет в хранилище, компонент не сможет рендериться, поэтому сетевой запрос будет всегда выполняться.

Таким образом, store-and-network позволяет жестко контролировать, как будет отображаться дерево компонентов с различными требованиями к данным. Сетевой запрос будет выполняться всегда — политика выборки просто диктует, как Relay должен обрабатывать рендеринг/приостановку рендеринга частей вашего поддерева компонентов с учетом текущего состояния вашего хранилища.

В случае (b) хорошим примером будет ситуация, когда вы объявили фрагмент, определяющий требования к данным для компонента, который ранее был размонтирован, но был совместно использован компонентом в другом месте вашего приложения. Отсутствующие данные = выполнение сетевого запроса + приостановка рендеринга в мире Relay.

Другими словами, политика выборки на самом деле касается того, как ваше приложение отрисовывается, а не того, как ваше приложение извлекает данные.

person JosephHall    schedule 28.11.2020