#angular #ngrx #ngrx-store
#angular #ngrx #ngrx-store
Вопрос:
Используя Angular и ngrx, я хочу перейти к маршруту и убедиться, что требуемые данные доступны в ngrx / store. Я использую действие / эффект / редуктор ngrx / store для физического вызова API. Компонент, загружаемый маршрутом, получает доступ к данным через хранилище, поскольку другие части системы могут обновлять данные.
Если данные не загружаются, отправляется действие LOAD_FAILED, которое может быть обработано множеством способов.
Должен ли я использовать защиту или распознаватель? Каковы некоторые другие плюсы и минусы каждого подхода? Что вы пробовали, и если бы у вас снова было время, вы бы сделали это таким же образом? Ниже приведены некоторые из моих мыслей.
Вариант 1: Защита
При доступе к маршруту canActivate функции guard проверяет, есть ли данные в хранилище, и, если нет, загружает их из API и добавляет в хранилище . Если данные не загружаются, canActivate вернет значение false (как наблюдаемое).
Недостатком этого подхода является то, что «загрузка данных не должна входить в обязанности защиты», но имеет преимущество в предотвращении доступа, если данные не могут быть загружены, и маршрутизатор может обработать переход к «не найдено», оба из которых входят в обязанности.
Вариант 2: распознаватель
Когда доступ к маршруту получен, и любые другие средства защиты разрешили активацию, вызывается распознаватель. Этот распознаватель проверяет, есть ли данные в хранилище, и если нет, запускает действие ЗАГРУЗКИ, чтобы загрузить из API и добавить в хранилище. Затем, как только данные были загружены, распознаватель возвращает некоторые произвольные данные, которые отбрасываются маршрутом / компонентом, поскольку компонент использует хранилище. Если данные не загружаются, что-то перенаправляет на страницу «Не найдено»
Недостатком этого подхода является то, что распознаватель не используется в традиционном смысле, например, данные, которые он возвращает, отбрасываются. Кроме того, либо распознавателю необходимо перенаправить на 404, когда он не найден, либо LOAD_FAILED необходимо перенаправить. Это добавляет сложности, поскольку могут быть случаи, когда LOAD_FAILED не следует перенаправлять, например, когда фоновое действие запускает загрузку. С другой стороны, за загрузку данных отвечает распознаватель.
Комментарии:
1. Я лично использовал бы guards и resolvers именно для того, что они есть. Однако, поскольку вы используете ngrx и вам не нужно беспокоиться о получении предварительно извлеченных данных из преобразователей, я думаю, с вами все будет в порядке в любом случае.
2. @AnjilDhamala, спасибо за ваш комментарий. На самом деле вопрос здесь в том, что более уместно — защита предназначена для разрешения / предотвращения доступа, но в этом случае мы хотим защититься от «отсутствия данных». Распознаватели предназначены для выборки данных, так что это кажется логичным. Если бы распознаватели выполнялись до guardians, имело бы смысл использовать оба, но поскольку guardians выполняются первыми, я не совсем понимаю, какой подход лучше!
Ответ №1:
Я думаю, в вашем случае вас устроят либо Guard, либо Resolvers.
Я лично считаю, что распознаватели больше подходят для предварительной выборки данных. Я не вижу проблемы в отбрасывании данных. Вы также можете предоставить некоторую полезную информацию о извлечении данных для конечного компонента (например, если данные были доступны только частично).
Я действительно не понял, что вы подразумеваете под недостатком выполнения перенаправления в распознавателе. Я полагаю, что такой проблемы нет, вы можете обрабатывать перенаправления в распознавателе, как это продемонстрировано в руководстве по Angular. В базовом случае сбоя выборки событие маршрутизации будет отменено, и пользователь останется на текущей странице.
Единственное реальное преимущество использования Guard, как я вижу, заключается в том, что вы можете выполнять их в очереди. Потенциально это позволяет создавать более универсальные и повторно используемые классы защиты, где каждый Guard отвечает за извлечение определенных битов данных. Распознаватели, с другой стороны, в большей степени зависят от маршрута, а не от данных.