forkJoin([
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
]).subscribe((...) => ...);

Вроде рабочий вариант.

Да то что рабочий это понятно, я проверил перед тем как написал)
Может можно как-то лучше

А ngRx не масштабируется?)

ngrx - это один глобальный стор, даже когда вы делите его на модули, они в конце концов объединяются в одну большую глобальную шину данных с одним ед объектом(стором)

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

По вашей постановке, логика forkJoin подходит и обработка ошибок там так и делается.

Спасибо, тогда я спокоен)

Я как раз в процессе познания деталей. Так что вопрос.

А чем плох глобальный стор? И чем хорошо его делить в рамках одного приложения?

(мне не понятна проблематика масштабируемости именно стора в веб-приложении)

Please write in englush to make more benfites

он плох тем же, чем и хорош) чем больше ваше приложение, тем больше в нем редьюсеров, экшенов, эффектов - а шина данных при этом остается одна.
p.s: если у вас ssr, то насколько мне известно, с акитой могут быть трудности, поэтому этот вопрос стоит обсуждать отдельно

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

It's russian community

forkJoin([
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
  ...pipe(catchError(...) => of(...)),
]).subscribe((...) => ...);

Если обработка одинаковая, то можно убрать повторяющийся код в функцию, куда прокидывать массив потоков и получать уже с добавленной обработкой ошибок

Либо в кастомный оператор

Да, так и сделал)

В плане - вынес повтор

забыл еще добавить один аргумент в минус всем стейтменеджерам: усложнения кода там, где казалось бы, все просто. Например: у нас есть два компонента, которые берут данные из одного участка стора. Мы хотим, чтобы когда компоненты не использовались, то данные из этого участка очищались(зачем засорять память?). Мы добавляем экшн на очищение и дергаем его в unsubscribe. Как быть, если наша страница разделена на 2 подроута. На обоих наши компоненты, при этом, пользователь уходит с одного подроута на другой и компонент удаляется) что происходит со вторым? правильно, он тоже очистится, ведь был экшн) как это исправить? Боюсь, что придется написать доволно много кода)

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

То же самое можно сделать и с помощью сервисов не привязываясь к конкретному стейт менеджеру

Да, знакомо, у меня в приложении сейчас так и есть. Пришлось написать wrapper для тех компонент, которые используют на разных роутах одни и те же компоненты и хранить тип компоненты(в зависимости от роута) в сторе. Тогда мы можем разделить сторы действительно разных компонент по роутам, хоть они и используют одни и те же классы. Не уверен, что это верный подход, но он работает.