@ngrx с API, как распознать разницу в результатах?
Я столкнулся с проблемой и чувствую, что со временем она становится только хуже. Проблема, с которой я столкнулся, заключается в том, что вызовы API могут давать одинаковые результаты, но с немного разными атрибутами, и у меня возникла проблема с тем, чтобы понять, как реализовать это с помощью @ngrx.
Пример:
- У нас есть роль пользователя:
system user.- Пользователи, не вошедшие в систему, используют
/api/activitiesдля получения действий. System userиспользует/api/su/activitiesдля получения действий.- Оба вызова API возвращают действия, но один из них также возвращает атрибут
activity_categories.
- Пользователи, не вошедшие в систему, используют
- Перед тем, как
SUвходит в систему, они загружают действия с/api/activities, и результат сохраняется в магазине. - Затем
SUвходит в систему, и теперь ему нужны дополнительные данные для каждого действия (activity_categories), и он проверяет, получены ли уже действия. Если они есть, он пропускает вызов API (/api/su/activities). SUтеперь выдает ошибку, потому что каждое действие не имеет своих категорий (activity ['activity_categories']).
Итак, есть ли разумный способ обойти это? :)
@Ricardo Проблема, о которой я говорил выше, заключается в том, что он даже не выполняет другой вызов api, потому что первая выборка действий уже находится в магазине.
@RamoMislimi, разве ты не контролируешь магазин?
почему бы не очистить хранилище, снова установив начальное состояние после входа в систему ... Это похоже на выполнение 2 операций, очистку хранилища, выполнение вызова отдыха
@Ricardo Я тоже думал об этом, и это возможное решение. Но это не возможное решение, если вы должны иметь возможность посещать обе страницы после входа в систему. Я мог бы заблокировать пользователю переход на страницу, где сделан /api/activities, но это не лучшее решение. Один из вариантов - создать аналогичную страницу, но с другим вызовом API (/api/su/activities).
Можете ли вы выполнить рефакторинг вызовов API в /api/activities и /api/su/activitycategories, а затем дополнить данные, уже находящиеся в состоянии, данными категории активности? Затем на странице SU, в случае, когда данные /api/activities уже присутствуют, вы просто выполняете второй вызов, в случае, когда его нет, вы делаете оба.
Ответы 1
Есть два возможных решения этого. Самый простой - игнорировать тот факт, что это «одни и те же» данные, и хранить два разных набора данных о деятельности, один обогащенный, а другой нет, в хранилище состояний как совершенно разные вещи.
Другой вариант - провести рефакторинг API, чтобы предоставить конечную точку, которая просто возвращает дополнительные данные категории для действий (например, /api/su/activitiycategories), а затем вызывать только эту вторую конечную точку, если у вас уже есть базовые данные об активности в состоянии. Затем вы обновите данные о состоянии дополнительными данными категории.
Возможно, вам потребуется сохранить флаг в состоянии (например, «activityEnrichedWithCategories»), чтобы контролировать, нужно ли вам выполнять этот вызов или нет. В случае, если базовые действия не существуют, вам нужно будет выполнить оба вызова для получения расширенных данных или вместо этого вызвать конечную точку /api/su/activitycategories/.
Этот второй вариант намного сложнее реализовать, но, если есть много действий, он может стоить дополнительных усилий.
Согласен, второй вариант намного сложнее. Возможно, для этого можно сделать общее решение, может быть, я могу указать при использовании select(x) для выборки, чтобы также указать, какие типы значений мне нужны, и если это не так, он выполняет выборку (как вы упомянули) для получения дополнительных данных и заполнения уже сохраненных данных. Но делать что-то подобное и отнимать много времени - это чертовски беспорядок. Думаю, я просто разделю их на отдельные состояния (su-activities и activities). Спасибо за помощь. Я не эксперт в @ngrx и просто не знал, упустил ли я что-то еще.
@RamoMislimi Конечно, есть способы сделать то, что вы описываете, но я не уверен, что это лучшая структура. Другим более чистым решением было бы подписаться на ваши действия с помощью select (x), а затем в вашем контроллере, если вы обнаружите, что у вас нет обогащенных данных, запустите запрос, чтобы получить его, и поместите его в состояние. Затем контроллер автоматически получит обновленные данные. Если вы хотите, чтобы шаблон компонента не получал данные до тех пор, пока категории не будут заполнены, вы можете включить фильтр. Я могу написать это как еще один ответ, если это звучит правдоподобно?
Хорошо, я думаю, что выберу менее сложное решение, в котором у меня есть отдельное состояние (или даже хранилище) для каждой роли пользователя. Когда я думаю об этом решении, я думаю, что менее сложное легче масштабировать и вызовет меньше головной боли, особенно если другие разработчики собираются работать с кодом. Спасибо за помощь и отличный ответ :)
Я предлагаю вам предопределить activity_categories как null в вашем объекте, тогда, если парень войдет в систему, вы можете присвоить значение этой переменной