Обсудим: composable, sharedComposable, pinia. Попробуем понять: а нужно ли вообще управлять состоянием? что значит управлять? кто должен управлять? и Какие существуют подводные камни в управлении состоянием. Методы и идеи их преодоления. Готовые библиотеки или примеры кода для использования.

Контекст статьи — PWA, в других контекстах тоже будет работать, но это не точно.

В статье будет критика Pinia. Если ты любишь этот инструмент, и не готов к конструктивной критике — лучше не читать, либо давай подискутируем в комментах. Я открыт к диалогу. Если ты уже думаешь о замене или уже ищешь её — это для тебя. 

Чувак, уже есть 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 с пояснениями.