Если эта переменная только для "считывания", то тогда конечно же можно.

но при этом всё же важно понимать, откуда она приходит, где она на самом деле живет. Там она и должна меняться.

Как сделать миниатюру изображения при загрузке как в вордпрессе в ларавел?

https://www.dropzonejs.com/#usage пробовал, но не получается
filepond тоже не получилось

https://innostudio.de/fileuploader/#download нашел такое, но тут платно

Кстати, вот ссылка на Angular Kharkiv meetup: https://www.eventbrite.nl/e/angular-kharkiv-meetup-8-tickets-114127494408?ref=estw&fbclid=IwAR1mAZydu9rsOfKk1xNWsCp_cyFj7snvMGJe3zBeQKO4yJVtrbtapBGL1zc

Мне самому не приходилось ещё с таким сталкиваться, но если убрать кэш из graphQL и использовать только как супергибкий API layer, а само кэширование и менеджмент этот стейта перенести в ngrx или подобные библиотеки, тогда вроде можно с этим работать. Но тут получается немало движущихся частей и тут как раз нужна будет огромная дисциплина :)
Опять же, это теория.
Я слышал с Firebase так работают, чтобы уменьших количство read/writes, что влияет на затраты в том числе.

Я бы все же попробовал бы без усложнений сначала.

Штука в том, что у нас уже есть input/output и состояние компонента. Ну и что там внутри меняется – вопрос именно что компонента, его ответственность.
Сам ngrx и не только он создаёт свой отдельный механизм передачи и изменения контекста. И тут нужно понимать уже что там будет меняться, а что может готовиться к view компонента и не влиять на стейт.

Кеш убирать не нужно, просто не использовать его как стейт скорее, без локальной схемы и всяких field policy

Согласен, но передавать все через input/output не скейлится, не так ли?

Ну не все конечно, я скорее про приоритеты. Где можно, лучше передать явно, где нет, то приходится уже внешние сервисы подключать.

Много input/output это как раз симптом, что что-то не так в архитектуре и пора уже подключать доп абстракции

более того, если компоненты начинают передавать глубже, а сами не использовать, начинается property drilling.
Так же есть проблемы, если нужно комбинировать данные с разных источников и т.д.
На моем опыте это быстро начинает ломаться

да, согласен

О да, вот тут нужно уже думать

если мы не говорим про graphQL или "реактивные" источники как websockets или firebase, то, как по моему мнению, надо сначал обернуть в stateless services, а потом уже оборачивать в service, которые будут ближе привязываться к самому дереву компонентов, и они уже могут хранить стейт

Пытаюсь представить srateless+stateful services. На твой взгляд, какую проблему решит такой подход? Тесть у тебя будут сервисы которые врапают другие сервисы значит в компонентах не будут юзаться стейтфул сервисы на прямую.

Stateless - это абстракция для HttpClient. stateful - это уже либо сами сервисы, либо тот же ComponentStore, либо более глобальные стейт менеджменты.

Да я это понимаю

Тоесть доп абстракция решит проблему coupling'а но если у тебя приложение "калькулятор" то вряд ли это нужно, если у тебя в приложении всего там пару сервисов 🤔