Добрый день! Вопрос об организации хранения данных в приложении. Сейчас

в нем работает все на сервисах и самописных классах эмулирующими логику работы с данными таких как NGRX, NGSX или Akita. По началу все было круто, но количество данных растет, а удобство работы с кастомными решениями оставляет желать лучшего и требует рефакторига. Из личного анализа сложилось впечатление что изобретать велосипед не стоит и проще взять одно из готовых решений вроде таких как NGRX, NGSX или Akita. Стоит ли переезжать на один из стейтменеджеров или зарефакторить и улучшить кастомное решение?

Если вас устраивало кастомное решение, то обратите внимание на это https://ngrx.io/guide/component-store

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

О, наконец то кто то еще напоролся на это, а то тут все топят за кастом, но складывается впечатление, что с кастомом реально далеко никто не заходил - мы у себя тоже в какой то момент напоролись на сложность поддержки. В вашем случае я б предложил прикинуть, проблемы возникают именно из за инструмента, а не из за кривых/неудобных данных/процессов/подходов?

Если не нравится громоздкость NGRX, посмотрите https://github.com/ngneat/elf

бери акиту

никто не заходил. все на пет прожектах

А можно поподробнее про проблему, а то как-то абстрактно всё. В чём сложность поддержки? У меня к примеру есть папка со стейтом, в папке делаю кучу сервисов, которые будут отвечать за определенный набор данных. Единственная проблема в том, как эти сервисы организовать. Но это больше проблема архитектуры. И она не выглядит такой уж страшной по сравнению с бойлерплейтом стейтменеджеров

Стикер

Ну значит все тут сплошь архитекторы от бога)

архитекторы "Ну, с богом!"

за 6 дней что угодно

А есть какая-то конкретика, а то "стало неудобно" и "стало казаться велосипедом" - это как-то очень абстрактно

хм... есть базовый класс, который описывает логику хранения данных с методами: добавить, удалить, изменить, вернуть весь список, вернуть по id, полю. Внутри него есть 2 BehaviorSubject, один для получения начального состояния (или если мы полностью переписываем стор данными), второй для получения единичных изменений. Для каждого типа данных мы делаем инстанс стора. Все хорошо работает, пока в компоненте выводится 1 тип данных, просто подписываемся на стор и все. Когда в компоненте нужно вывести несколько типов, начинаются танцы со сторами. В компоненте идет куча подписок на разные сторы, которые в конечном счете преобразуются в один общий для отрисовки. В итоге имеем кучу подписок на сторы в компоненте, что не круто и сейчас от этого избавляемся. Создаем сервис-обертки для каждого компонента, которые собирают подписки из разных сторов в одну общую.

а ngrx вас как спасет от вашей кучи подписок? у него тоже потоки для получения данных. все тож самое будет

Мне лично больно смотреть, как в простейших сценариях использует стм и прочий оверинжигиринг. Я не думаю, что для того, чтобы показать данные с сервера в табличке и отправить данные из формы на сервер, нужен какой-то опыт с стм. Просто HttpClient, который описан в документации. Проблема ngrx, как и redux, не в самом подходе, а в его ультимативности, всё делают через ngrx. Я считаю, что простые вещи надо делать просто. И то, что где-то в приложении есть пара сложных кейсов, не означает, что всё остальное теперь надо усложнить

Бизнесу таки эксперименты не понравятся, ибо время деньги)

не использовать ок если сценарий и останется простейшим

без ресерчей вы рискуете еще больше денег потерять

Ужас какой-то

норм же или что конкретно не понравилось?

Вообще все говно. Нейминги ужасные, api безидейный как и вся либа.

Вы описали нормальных подход (различные источники и форматы данных и сервис - фасад для компонента, в котором лежит комбайн данных нужных компоненту и логика общения со всем чем нужно), только с попыткой как-то унифицировать все под одну гребенку. Бывает такое что ангуляровский клиент работает с разными апихами, в этом случае попытка все супер унифицировать вызывает боль. Приятно написать stateless сервисы для общения с чем-либо, stateful сервисы для хранения и апдейта данных. Таких вот ребят будет много и желательно чтоб они были переиспользуемые. Дальше можно данные подгонять под удобный компоненту формат в сервисе-фасаде или же прям в компоненте, используя отдельные сервисы-конверторы. В этом случае все данные могут в нужных фасадах/компонентах контроллируемо по необходимости переплетаться. Но важно пилить атомарные простые сервисы чтоб их можно было без труда композировать. Ну и именовать их чтобы не путаться)