Не совсем поняла эту часть — «когда работаешь с хуками нельзя конфигурировать их литералами». Уточните, пожалуйста.

Если сравнивать DX, то представляется такой образ: Redux — большая организация со сложной бюрократией, mobX — частная фирма с теми же услугами, Effector — онлайн-стартап.

Как я отмечаю в статье, Effector мне понравился больше тем, что оказался понятнее и нагляднее. Не спорю, что для кого-то другого Redux лучше :)

Чтобы понять, почему подход с прокидыванием экземпляра класса — плохой, давайте заменим его на нечто знакомое в мире Vue. Экземпляр класса — это ничто иное, как экземпляр родительского компонента, только вынесен в другой файлик. То есть у нас есть состояние, есть методы, которые это состояние меняют.

Если обратиться к документации, где сказано, что мутирование props — это плохо, потому что приводит к боли, получается, что прокидывание самих методов с их последующим вызовом — это плохо и больно.

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

Взаимодействие с компонентами осуществляется за счет публичного интерфейса — props/emits. В большинстве проектов и Vuex (помянем) / Pinia не нужны, так как хранить глобальное состояние отдельно от представления нужно далеко не всегда.

Однако если уж прям хочется вынести логику в сервис, создав франкенштейна во фронтенде с костыльной слоистой архитектурой, то вам в Angular использование Vuex / Pinia будет наилучшим решением, чем придумывать слой данных на коленках. Даже в этом случае нужно будет обеспечивать высокую связанность компонентов и держать store/view слои где-то рядом (посмотрите на Gitlab исходники)

Кратко: Нет, так делать не нужно, так как в долгой перспективе приведет к сильной связности/сложному дебагу и ужасному опыту тестирования