Какая польза от сервисов, если вы используете ngrx/store и эффекты?

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

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

Мой магазин ориентирован на простые API-подобные действия, которые короткие и легко тестируются, например

  static INITIALIZE_CONFIG_REQUEST = 'INITIALIZE_CONFIG_REQUEST';
  static INITIALIZE_CONFIG_SUCCESS = 'INITIALIZE_CONFIG_SUCCESS';
  static INITIALIZE_CONFIG_FAILED  = 'INITIALIZE_CONFIG_FAILED';
  static INITIALIZE_CONFIG_TEMPLATE_ERROR  = 'INITIALIZE_CONFIG_TEMPLATE_ERROR';

  createInitializeConfigRequest() { // separate from invoking call for easier testing
    return {
      type: ConfigActions.INITIALIZE_CONFIG_REQUEST,
      httpRequest: {
        url: 'api/path/to/config',
        successAction: this.createInitializeConfigSuccess,
        failedAction: this.createInitializeConfigFailed,
        validateResponse: (data) => this.checkTemplate(data)
      }
    };
  }
  initializeConfigRequest() {  // called by config.service
    this.store.dispatch( this.createInitializeConfigRequest() );
  }

  createInitializeConfigSuccess(data) {
    const payload = data;
    return {
      type: ConfigActions.INITIALIZE_CONFIG_SUCCESS,
      payload
    };
  }

  createInitializeConfigFailed(error) {
    return {
      type: ConfigActions.INITIALIZE_CONFIG_FAILED,
      payload: {
        error
      }
    };
  }

С помощью этого шаблона мне проще добавить промежуточное ПО, например, обрабатывающее проверку httpRequest и Response выше.

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

  genericActionHandler(state, action) {
    if (!action.payload) {
      return state;
    }
    const newState = {...state};
    Object.assign(newState, action.payload);
    return newState;
  }

Надеюсь, это даст вам представление о моей архитектуре.

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

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

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

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

Дополнительное чтение:

https://medium.com/@m3po22/stop-using-ngrx-effects-for-that-a6ccfe186399

https://ngrx.io/guide/effects