@ngrx с API, как распознать различия в результатах?

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

Пример:

  • We've got a user role: system user.
    • Non-logged-in-users uses /api/activities to fetch activities.
    • System user использует /api/su/activities для получения действий.
    • Оба API-вызова возвращают действия, но один из них также возвращает атрибут activity_categories.
  • Прежде чем SU войдет в систему, они извлекают действия с /api/activities, и результат сохраняется в хранилище.
  • Затем SU входит в систему и теперь ему нужны дополнительные данные для каждого действия (activity_categories) и проверяет, были ли уже получены действия. Если они есть, он пропускает вызов API (/api/su/activities).
  • SU теперь выдает ошибку, потому что в каждом действии отсутствуют категории (activity['activity_categories']).

Итак, есть ли умный способ обойти это? :)


person Ramo Mislimi    schedule 31.07.2018    source источник
comment
Я предлагаю вам предварительно определить activity_categories как null в вашем объекте, тогда, если парень войдет в систему, вы можете присвоить значение этой переменной   -  person Ricardo    schedule 31.07.2018
comment
@Ricardo Проблема, о которой я говорил выше, заключается в том, что он даже не выполняет другой вызов API, потому что первая выборка действий уже находится в магазине.   -  person Ramo Mislimi    schedule 31.07.2018
comment
@RamoMislimi, разве у тебя нет контроля над магазином?   -  person Devon    schedule 31.07.2018
comment
почему бы не очистить хранилище, снова установив начальное состояние после входа в систему... Это похоже на выполнение 2 операций, очистку хранилища, выполнение остаточного вызова   -  person Ricardo    schedule 31.07.2018
comment
@Ricardo Я тоже об этом думал, и это возможное решение. Но это невозможное решение, если вы должны иметь возможность посещать обе страницы при входе в систему. Я мог бы запретить пользователю переход на страницу, на которой сделано /api/activities, но это не очень хорошее решение. Один из вариантов — сделать аналогичную страницу, но с другим API-вызовом (/api/su/activities).   -  person Ramo Mislimi    schedule 31.07.2018
comment
Можете ли вы преобразовать вызовы API в /api/activities и /api/su/activitycategories, а затем обогатить данные, уже находящиеся в состоянии, данными категории действий? Затем на странице SU, в случае, когда данные /api/activities уже присутствуют, вы просто делаете второй вызов, в случае, когда он отсутствует, вы делаете оба.   -  person Mark Hughes    schedule 31.07.2018


Ответы (1)


Есть два возможных решения. Проще всего игнорировать тот факт, что это «одинаковые» данные, и хранить два разных набора данных об активности, один обогащенный, а другой нет, в хранилище состояний как совершенно разные вещи.

Другой вариант — реорганизовать API, чтобы предоставить конечную точку, которая просто возвращает дополнительные данные категории для действий (например, /api/su/activitiycategories), а затем вызывать только эту вторую конечную точку, если у вас уже есть базовые данные активности в состоянии. Затем вы обновите данные состояния дополнительными данными категории.

Вам может потребоваться сохранить флаг в состоянии (например, «activitiesEnrichedWithCategories»), чтобы контролировать, нужно ли вам делать этот вызов или нет. В случае, когда базовые действия не существуют, вам нужно будет выполнить оба вызова, чтобы получить расширенные данные, или вместо этого вызвать конечную точку /api/su/activitycategories/.

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

person Mark Hughes    schedule 31.07.2018
comment
Я согласен, второй, если гораздо сложнее. Возможно, для этого можно сделать общее решение, может быть, поэтому я могу указать при использовании select(x) для выборки, а также указать, какие типы значений мне нужны, и если это не так, он выполняет выборку (как вы упомянули) для извлечения дополнительных данных и заполнения уже сохраненных данных. Но это похоже на адский беспорядок, чтобы делать что-то подобное и отнимать много времени. Думаю, я просто разделю их на их собственные состояния (su-activities и activities). Спасибо за помощь. Я не эксперт в @ngrx и просто не знал, упустил ли я что-то еще. - person Ramo Mislimi; 01.08.2018
comment
@RamoMislimi Конечно, есть способы сделать то, что вы описываете, но я не уверен, что это лучшая структура. Другим более чистым решением было бы подписаться на ваши действия через select(x), а затем в вашем контроллере, если вы обнаружите, что у вас нет обогащенных данных, запустите запрос, чтобы получить его, и поместите его в состояние. После этого контроллер автоматически получит обновленные данные. Если вы хотите, чтобы шаблон компонента не получал данные до тех пор, пока категории не будут заполнены, вы можете включить фильтр. Я могу написать это как еще один ответ, если это звучит правдоподобно? - person Mark Hughes; 01.08.2018
comment
Это хорошо, я думаю, что я выберу менее сложное решение, в котором у меня есть отдельное состояние (или даже хранилище) для каждой роли пользователя. Размышляя об этих решениях, я думаю, что менее сложное решение легче масштабировать и оно вызовет меньше головной боли, особенно если другие разработчики будут работать с кодом. Спасибо за помощь и отличный ответ :) - person Ramo Mislimi; 02.08.2018