Ember Substates с данными Ember после хранения уже имеет данные

Question

Я прочитал документы Ember, касающиеся подсостояний и т. Д., И я понимаю, как это работает.В моем текущем приложении мои loading.hbs и другие дочерние шаблоны load.hbs работают нормально.

Я просто хочу обсудить вариант использования.

1. На моем маршруте A, в моей моделиЯ выполняю функцию fetchAll для своей модели.
2. Я перехожу на маршрут A, первый раз отправляется запрос API и отображается экран загрузки.
3. Теперь я перехожу на другой маршрут B.
4. Теперь я возвращаюсь к первому маршруту A, запрос API снова отправляется, но на этот раз экран загрузки не отображается.

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

ВОПРОС

Теперь я хочу знать, является ли это поведение Ember по умолчанию с данными Ember по умолчанию?

Чтобы отобразить этот экран загрузкимне нужно будет что-то делать вручную?

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

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

Заранее спасибо.

Answer 1

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

Если записи уже были, тогда обещание будет выполнено немедленно, поэтому я не• см. экран загрузки для уже загруженной записи, в то же время Ember-Data также синхронизируется с бэкендом и повторно отображает шаблон.

Документы Ember Model

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

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

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

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

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

Answer 2

Теперь я хочу знать, является ли это поведение Ember по умолчанию с данными Ember?

Да, это поведение по умолчанию данных Ember, когда вы делаете findRecord илиfindAll, где shouldBackgroundReloadRecord или shouldBackgroundReloadAll событие адаптера соответственно, по умолчанию имеет значение true.Вы можете отключить это, вернув false и убедившись, что shouldReloadAll или shouldReloadRecord соответственно установлены на true, чтобы гарантировать, что запрос всегда попадает в API, а не извлекается из кэша.

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

Чтобы показать этот экран загрузки, мне придется что-то делать вручную?

Вы также можете прочитать это