Чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы 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

Сегодня этому каналу 1 год.

Время вспомнить первый пост

По сей день это лучший учебник для изучения Vue.js на русском языке.

#vuefaq #learning #architecture #book

Кто занимается микрофронтендами - познавательная статья Micro Frontends на сайте Мартина Фаулера

#microfrontends #architecture #bestpractices

Комментарии к прошлому посту ярко показывают, стоит ли тащить в свой проект чудо природы под названием FSD.

Модульная архитектура даёт понятную четкую декомпозицию проекта, хорошо разделяя ShoppingCart от UserAccount, например. Позволяя видеть в файловой панели только относящиеся к нужному модулю ресурсы, и работать над модулями независимо.

Общие элементы типа BaseButton можно держать в App, а можно выделить под них отдельный проект (вроде своей дизайн системы) и подключать папкой ui через git submodules. Так же, как и объекты типа api.

Между модулем и однофайловым компонентом есть промежуточные структуры - виджеты типа FileUploader, например, в которых есть чисто их композаблы, утилиты, компоненты, типы. Их удобно держать в своих папках без разделения по поддиректориям.

Довольно сложный вопрос, где держать и как наименовать файлы с бизнес-логикой - как реактивной, так и обычной. Однозначного совета пока нет. Скорей тут надо использовать программерские подходы из обычного ООП.

#architecture

Основные принципы локально-ориентированной (Local-First) разработки

Локально-ориентированная разработка имеет сходства с подходами offline-first, но идет дальше, уделяя больше внимания контролю пользователя и владению данными. Вот ключевые принципы, определяющие настоящую локально-ориентированную веб-приложение:

- Мгновенный доступ: Пользователи могут немедленно получить доступ к своей работе без ожидания загрузки или синхронизации данных (отсутствие спиннеров).

- Независимость от устройства: Данные доступны на разных устройствах без проблем.

- Независимость от сети: Основные задачи могут выполняться без подключения к интернету.

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

- Долговечные (Future-Proof) данные: Данные пользователей остаются доступными и пригодными для использования с течением времени, независимо от изменений в программном обеспечении.

- Встроенная безопасность: Безопасность и конфиденциальность являются фундаментальными аспектами дизайна.

- Пользовательский контроль: Пользователи полностью владеют и контролируют свои данные.

#bestpractices #architecture

Options API - это FSD
Composition API с composables - модульная архитектура.
(аналогия)

FSD в основу иерархичного разбиения ставит программный функционал. Модульная - доменные сущности

Можно провести аналогию c физиологией человека

Можно изучать человека разбивая его на руки, ноги, тело, голову и внутри уже по органам, тканям и т.д.

FSD же на верхнем уровне разбивает сперва по органам и тканям - кровеносная система, ЖКТ, мышечные ткани, и внутри уже разбивает по доменам - рот и кишечник внутри ЖКТ

Так же и с переходом от Options API к Composition API. Было разбиение по фичам (options), стало - по бизнес / доменным сущностям (композициям).

Так лучше.

#fsd #architecture

Иллюстрации к принципам ООП из выдающейся книжки Graddy Booch Object-Oriented Analysis and Design with Applications

Очень полезна фронтендерам в том числе

#oop #architecture #gradybooch

Решения для проблемы выше

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

К созданию сторов / модульных рефов надо подходить так же ответственно, как к проектированию схемы реляционной базы данных. Это координатный базис, и в нем не может быть перекрестных зависимостей.

Если есть логика, которая работает и с А, и с B, то, скорей всего, она прикладная для этих сторов, и должна лежать в отдельной сущности (компоненте, композабле, простом или реактивном модуле, сторе).

2. setTimeout / nextTick, как на картинке. Работает и с модульными рефами, но выглядит уродливым костылём

3. Шина событий (eventBus) для сообщений между сторами. Как самостоятельное решение возможно, но в данном случае опять же костыль.

4. Если refA в примере вынести в отдельный модуль, то ошибка пропадет. То же самое, скорей всего, справедливо и для сторов, но будет выглядеть неуклюже. Выносить надо не голый стейт, а разделять стор грамотно, по ответственности.

5. Не надо пихать реактивность туда, где можно обойтись без нее. Если переменная B зависит от А, и источников изменения А всего один-два, то необязательно ставить watch над А в B, можно обновлять B императивно напрямую. Это уберет прямую зависимость от А в B (если код в А уже как-то использует B), а также повысит читаемость и производительность. В первую очередь касается кода, который работает с бэкенд API.
Так же приоритетно, как и пункт 1.

#store #reactivity #architecture

Атрибуты хорошего кода

Хороший код (ПО) обладает рядом атрибутов, которые делают его удобным для чтения, поддержки и развития. Вот ключевые характеристики:

1. Читаемость

Понятные имена переменных, функций, классов (например, calculateTotalPrice() вместо calc()).
Единый стиль (консистентность в именовании, отступах, структуре).
Комментарии там, где логика неочевидна (но без избыточности).

2. Модульность и структурированность

Разделение на функции/классы/компоненты (принцип Single Responsibility).
Низкая связанность (low coupling) – компоненты минимально зависят друг от друга.
Высокая связность (high cohesion) – код внутри модуля решает одну задачу.

3. Тестируемость

Покрытие тестами (код легко проверить на корректность).
Изолированность (зависимости можно подменить mock-объектами).

4. Эффективность и производительность

Оптимальные алгоритмы (O-нотация учитывается, но без преждевременной оптимизации).
Минимизация ресурсов (память, процессор, сетевые запросы).

5. Гибкость и расширяемость

Открытость/закрытость (Open/Closed Principle) – код можно расширять без изменения существующей логики.
Использование паттернов проектирования (например, Factory, Strategy, Observer).

6. Надежность и отказоустойчивость

Обработка ошибок (корректные исключения, logging).
Обработка edge-cases (крайние случаи, невалидные входные данные).

7. Поддерживаемость

Документация (хотя бы минимальная: README, docstrings).
Рефакторинг – код можно улучшать без страха что-то сломать.

8. Безопасность

Защита от уязвимостей (SQL-инъекции, XSS, CSRF и др.).
Валидация входных данных.

9. Совместимость и переносимость

Кросс-платформенность (если требуется).
Четкие зависимости (использование package managers: pip, pnpm, maven).

10. Соответствие стандартам и best practices

Следование языковым идиомам (Pythonic way, Java Code Conventions, Vue code style и т. д.).
Интеграция с CI/CD (автоматические тесты, деплой)

#architecture #code

Пара советов с утра от автора "Clean code" Боба Мартина

#architecture #bobmartin