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

Nlognconnect будет работать, автоматически отправляя данные пользователям/клиентскому устройству, вместо того, чтобы ждать, пока клиент явным образом запросит их. Но есть проблема, использующая только этот подход, и какое-то время это пустой экран.

Когда пользователь запускает приложение Nlognconnect, и если его пропускная способность/связь низкая, в таком случае пользователь какое-то время будет видеть пустой белый экран, пока что-то не будет получено с сервера. Такое поведение, безусловно, нежелательно.

Единственный способ рендеринга контента на телефоне пользователя, как только он/она запустит приложение Nlognconnect, — это использовать метод рендеринга Cache first, что означает рисование устаревших/кешированных новостных лент на пользовательском экране. телефон на короткое время. Это означает, что всякий раз, когда пользователь открывает приложение Nlognconnect, он будет видеть кешированную копию старых каналов, отображаемых на их телефоне, до тех пор, пока свежие новости/канал не будут готовы. Как только свежие данные будут полностью извлечены, они заменят кэшированные данные.

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

Redux + кеш для улучшения времени рендеринга.

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

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

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

Процесс загрузки нового поста должен быть следующим:

  1. Как только страница загрузится, отобразите кешированное состояние для пользователя и отправьте запрос на новые данные на сервер.
  2. Создайте поэтапное подмножество состояния Redux.
  3. Пока свежий контент извлекается, мы должны сохранять каждое взаимодействие с кешированными сообщениями.
  4. Как только запрос готов, мы применяем все взаимодействие с кешированным постом и свежими данными к поэтапному состоянию.
  5. Замените текущее состояние зафиксированным промежуточным состоянием.

Использование политики cache first и избыточности для рендеринга обеспечит значительное улучшение времени рендеринга.

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

Я что-то пропустил, или вы хотите добавить еще какие-то ключевые моменты? Прокомментируйте, пожалуйста.

Первоначально опубликовано на https://nlogn.in 9 мая 2020 г.