Vueist
888 subscribers
12 photos
34 links
Vue шитпостинг, желтуха, советы и мысли

Дополнительный канал к @zede_code от @zede1697
Download Telegram
createSharedComposable

Если бы меня спросили лучшие паттерны для освоения во Vue, я бы точно назвал одним из них shared composable. Почему и что это за фрукт такой?

Происхождение
Первое упоминание о shared composable было в RFC Vue посвященному Effect Scope. И там говорится о примере композабла useMouse который слушает перемещения мышки и возвращает это в виде реактивных переменных координат. И вроде логично, что это не самое легковесное действие. А если это нужно множеству компонентов? Да каждый компонент использующий useMouse подписывается на него и это становится уже ощутимо. Тогда почему бы просто не вынести в глобальный STM как Pinia? Отличный вариант, но он будет работать даже когда нет никого кому нужны эти данные. И вот тут на помощь приходит shared composable он умеет как STM шарить данные на множество инстансов, но при этом если никто его не использует, то "стор" уничтожается! При этом сам паттерн универсальный и все что вам нужно это обернуть обычный композабл в createSharedComposable. И да, как только все компоненты использующие useMouse будут размонтированы shared composable тоже отпишется от событий мышки.

Как это работает?

На самом деле весьма не хитрым образом. Оно использует API Effect Scope + счетчик подписчиков, когда подписчиков становится 0 он уничтожает текущий скоуп. Вот и все. А... возможно вам не совсем знакомо что же такое Effect Scope (однажды мой доклад на эту тему уже выложат на YouTube...). А вот поэтому этот паттерн и хорош, он заставляет вас слегка заглянуть поглубже в работу Vue. Я уже приложил ссылку на RFC, где крайне подробно расписано что такое реактивные скоупы и как они работают. Если совсем сократить и упростить, то эффект скоупы это как мешок для реактивности: он запоминает все вызванные watcher-ы и уничтожает их в нужный момент (да-да именно так работает setup в компонентах). А вместо onUnmounted вы можете использовать onScopeDispose.

А чем же так крут этот паттерн еще?
1. Учебный эффект позволяющий лучше понять работу Vue
2. Возможность оптимизации как в примере c useMouse
3. Он позволяет на SPA приложениях спокойно заменить Pinia или другой STM на себя, так как спокойно выполняет обязанности глобального стейт менеджера, только еще и умеет уничтожаться когда никому не нужен (с pinia я видел как люди вручную это дело пытаются зачищать)
4. Advanced DI. По сути созданный композабл это сервис который может жить внутри provide / inject и расшаривать данные и логику как STM, но только на определенной части приложения (я не раз видело как пытаются генерировать это с pinia + id стора)

А какие есть минусы?
- Это не самое SSR Friendly решение
- Этого API нет из коробки, поэтому вам придется либо писать его самим, либо взять из vueuse
- Можно при неаккуратном использовании натворить страшных вещей
- Алгоритм использует простой счетчик, поэтому циклическая зависимость приведет к невозможности уничтожения (если не создать ручной "рубильник")

Итого: классный паттерн имеющий крайне широкие возможности с дополнительным эффектом погружения в мир реактивности Vue, однозначно рекомендую к изучению
🔥315
Provide/inject
Часть 3: Используем API на практике

Во Vue у нас есть Suspense, но он уже кучу лет висит в Experimental, да и не нужен он особо сейчас во Vue в текущем виде (данное обсуждение я бы вынес в отдельный пост). Однако, что нам делать если мы хотим определять лоадеры в родителе, а дети подгружали бы данные и не парились насчет кто и как показывает лоадер и это вместо того, чтобы делать парады спиннеров (когда каждый компонент имеет свой лоадер) или 1 глобальный лоадер перекрывающий все приложение. Вот с таким запросом заходили в чате.

И решение достаточно простое:
1. Пусть компонент который может показывать лоадер запровайдит API ниже через useLoaderProvider
2. Дочерний компонент через API сможет его подгрузить через useLoader и достать оттуда функцию wait, которая принимает Promise и сообщает родителю, что мы грузим какие-то дочерние данные
3. Соответственно родитель может знать о всех загрузках и показывать Loader когда необходимо

Однако у этого решения есть 2 специфичных минуса
- При первом рендере родителя он еще не знает будут ли грузиться дети (можем первый рендер вообще ничего не рендерить как пример)
- Мы не можем показывать loader / дети по условному v-if и нам нужно думать, как их отображать (например через v-show)

И вот получается базовая реализация. Изучите ее пожалуйста, так как в ней использованы все советы из прошлых постов.

Однако, как поведет такая реализация себя если компонент с лоадером мы вложим в компонент с лоадером? Сейчас каждый компонент с лоадером порождает независимый лоадер: то есть лоадер выше не знает о загрузках которые идут от лоадера ниже. И иногда данное поведение нас устраивает, а что если мы хотим, чтобы наш компонент показывал Loader даже, когда грузятся внутренние лоадеры? В этом случае мы могли бы просто не использовать provide во внутреннем лоадере, если он увидит уже запровайженное значение. Таким образом получаем улучшенный пример.

Теперь мы имеем достаточное простое и лаконичное API для работы с лоадерами на проекте при этом обладая полной гибкостью в работе с ними. И такой подход было бы крайне затруднительно реализовать без механизма provide/inject

#di #my #learn #example
🔥21👍6🤨2