Во Vue-FAQ добавилась статья, описывающая используемые структуры для Vue 3 проекта - Flat, Atomic, Модульная, FSD, микрофронтенды, с небольшим сравнительным анализом.

#architecture #vuefaq

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

Но:
1. Это не композабл по определению
2. Там не обязательно рефы
3. Они не "глобальны"

В общем случае структура данного объекта - экспортируемые из ES модуля реактивные данные и функции для работы с ними.

Функционально они заменяют "сторы" Pinia. Называть их тоже stores двусмысленно и нелогично. Вообще, молиться на "глобальный стейт" после появления идеи JavaScript signals и их всевозможных реализаций, включая Vue Reactivity API, архаично.

Мне кажется, самое подходящее название для данной конструкции - [реактивный] бизнес объект (РБО). В них инкапсулируется логика предметной области и приложения, они не привязаны к конкретным компонентам, и по аналогии с другими языками и фреймворками, этот паттерн - Business Object - выглядит вполне подходящим.

Кроме того, позиционирование именно как "бизнес объект" будет требовать явного отделения от него инфраструктурного слоя - работы с Backend API, например. То есть, стимулировать использование лучших практик и наработок из других сфер разработки ПО, еще более переводя Vue.js из фреймворка для небольших проектов в разряд enterprise level решений.

#architecture #vuejs #reactivity #rbo #composables

Аспект проектирования при основных типах методологий разработки программных систем:

Каскад (waterfall) - заказчик дает четкие требования, по ним строится архитектура системы, программисты делают по ней код.

Гибкая (agile, XP, итеративная) - заказчик дает общие требования, по ним строится прототип архитектуры системы, программисты делают по ней код, систему показывают заказчику, вносятся корректировки, выпускается следующая версия и.т.д по кругу.

DDD (domain-driven design, предметно-ориентированная проектирование) - заказчик и программисты постоянно тесно работают над выработкой четкой модели предметной области, которая затем практически один в один становится скелетом архитектуры программной системы.

Каскад применяется для более-менее типовых задач и когда есть четкие требования (SRS, техзадание).
DDD увеличивает вероятность успеха при решении сложных задач, с нечеткими и меняющимися требованиями и необходимостью исследования предметной области.

#architecture

Чистая архитектура (Clean Architecture) — это способ разделения функционала по степени его близости к предметной области приложения.

Она даёт:

- Независимость от зависимостей. Архитектура вашей системы не зависит напрямую от существования какой-либо библиотеки. Это позволяет использовать фреймворки как инструменты, а не втискивать свою систему в их рамки.

- Тестируемость. Бизнес-правила можно тестировать без UI, базы данных, веб-сервера или любого другого внешнего элемента.

- Независимость от UI. Пользовательский интерфейс можно легко изменить. Например, веб-интерфейс может быть заменен на мобильный, без изменения бизнес-правил.

- Независимость от внешних сервисов. Вы можете заменить, например, MySQL на Mongo, поменять платедного провайдера или что-то еще. Ваши бизнес-правила просто ничего не знают о внешнем мире.

Именно по рекомендациями Clean architecture не следует обращаться к web API напрямую из стора. Подобные требования есть у многих методологий проектирования ПО

#architecture #cleanarchitecture

Мир IT крутится вокруг данных. Если задуматься, 99.999% времени любой компьютер внутри себя просто перекладывает данные с одного места в другое.

Data pipeline (конвейер данных) - это методика сбора, обработки и анализа данных, которые сперва собираются из разных источников в хранилища, структурируются и затем используются для разных целей.

В data lake складывают неструктурированные данные, data warehouse - уже структурированные, удобные для запросов.

#data #architecture

Для любителей FSD описание проекта на Vue на нем (тудушка)

В качестве выводов - констатация факта, что по FSD все сделать нельзя, даже такой маленький проект, и надо искать компромисс между FSD методами и не FSD методами в одном проекте.

#fsd #architecture

Аргументация против глобальных автоимпортов (типа тех, что в Nuxt) от Artyom Tuchkov

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент

3. Если проект вырастает во что-то большее, чем маленький пет, то количество компонентов уже не даст нормально и лампово работать с автоимпортами, если их названия будут собираться на основе папочек, где они лежат, а в больших проектах это вообще самоубийство

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

5. Ты уверен, что тришейкинг работает правильно и ты явно контролируешь загрузку каждого конкретного компонента в каком-либо месте, а не полагаешься на то, что за тебя это каким-то магическим образом сделает автоимпорт

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

#architecture #bestpractices #tip #nuxt

Чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы composable функции (называемые "функциями", хотя по сути это объект созданный через js замыкание - closure).

Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо Pinia/Vuex сторы.

Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в Tabs или каких-то виджетах), - то есть, в некотором локальном контексте. Для этого можно в общем родительском компоненте создать composable, который передать потомкам - либо через provide/inject (лучше), либо через props (не надо).

В этом случае данный реактивный объект будет жить в своем ограниченном контексте и не будет конфликтовать с оставшейся частью проекта.

#reactivity #bestpractices #architecture

Выражение "городить свои велосипеды" в IT заиграло новыми красками

Иногда оно используется по делу, но чаще имеет уничижительную форму, показывающую, что человек вместо популярного, раскрученного решения использует что-то свое или малоизвестное.

Если тебе нужен индексируемый поисковиками сайт, надо писать на Nuxt, а не городить отдельную или динамическую отрисовку. Нужно использовать VueUse, потому что это швейцарский нож в любых ситуациях. Для соединения с бэком надо всегда подключать Tanstack vue-query, потому что у него десятки тысяч звезд на GitHub, все его используют, и он легко решает кучу твоих проблем, о которых ты раньше даже не догадывался, но теперь они у тебя есть. Ну и, конечно, Tailwind!

О VueUse уже много говорилось. Как и об #ssr. Как и о Tailwind.

vue-query образовался из react-query, который действительно решал проблемы Реакта. Но во Vue нет этих проблем. Vue предоставляет все инструменты для эффективной и элегантной работы с бэкендом.

Проблема "решений", пришедших и навязываемых из других фреймворков - это действительно проблема. Человек, перешедший с бэкэнда и даже с другого языка программирования возможно будет писать более качественный Vue код, чем переучившийся с Реакта.

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

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

Ну и не будем забывать, что Vue - это тоже велосипед, написанный в эпоху диктатуры Angular, React, JQuery и других солидных, проверенных и общепризнанных решений.

#esse #architecture

#tip #architecture #meme