Чувак, уже есть Pinia, Pinia Colada, TanStack Query для Vue, зачем ещё один способ управлять состоянием во Vue?

Меня просто задолбало писать везде флаги отслеживания состояния для действий и делать store через фабричную функцию, как это делали наши праотцы в начале 2000-х. Запоминать зоопарк из разных composable-функций и хуков. Изучать какую-то другую систему реактивности, типа MobX, тоже не хочу. Это какой-то зашквар.

Я хочу использовать то, что есть: реактивность Vue везде, классы, методы. Хочу использовать классические шаблоны: SOLID, DDD и т.п. Хочу, чтобы Действие или запрос сами отслеживали и сообщали своё состояние. Хочу сконцентрироваться на бизнес-логике и писать меньше шаблонного кода.

И это возможно, покажу, как это работает на примере.

Это третий принцип. Весь список здесь.

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

Я исхожу из того, что код — это продукт, и первый пользователь — это коллега рядом. Он первым будет его смотреть, комментировать, рефакторить. Структура папок и кода — это дизайн продукта. Хороший дизайн соответствует принципу наименьшего удивления. Я делю код по смыслу согласно «решётке», поэтому организую структуру папок 2-я способами в зависимости от проекта:

— Layer Folder Structure (LFS)
— Scope Folder Structure (SFS)

Я люблю критику. Я ищу точки роста. Мне не хватает интеллектуального диалога, так чтобы были аргументы и контраргументы, примеры и антипримеры. Я в поиске качественной обратной связи: конкретной, предметной, аргументированной. Я хочу видеть свои "мертвые зоны" и вектора развития.

Допустим..., на работе у меня с этим проблемы, я прихожу на Хабр. Мне кажется, что тут тусуются те, кто может мне её дать. И действительно, здесь есть коллеги, кто умеет это сделать. Но есть те, кто, не умеет и не хочет это делать.

Почему-то мне кажется, что Хабр поддерживает последних, что он им помогает.

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

Я много писал на PHP + Symfony, писал на Angular, Vue. Я понимаю зачем DI-контейнер в Symfony, могу понять зачем он на фронте, особенно PWA. Я понимаю, какую проблему/задачу он там решает, почему он там нужен.

Но никак не могу понять, зачем он в микросервисах и даже сервисах большого размера на Go. И вот почему...

В предыдущей статье я описал как построить запрос к Эластику для полнотекстового и фасетного поиска. Здесь расскажу как организовать структуру и взаимодействие компонент, чтобы построить такой запрос.  

Мы используем vue, vuex, vue-route, поэтому дальше повествование будет в этом контексте. В основе взаимодействия лежат хуки компонент, хранилище состояния, роутер. Такую структуру можно воспроизвести на любом фреймворке с таким же составными частями.

О чем речь 

1. как реагирует UI, когда пользователь использует фильтры;
2. алгоритм формирования значений фильтров; 
3. шаблоны запросов и структуры индекса ElasticSearch с пояснениями.