Поговорим о Shared composables

Страшный термин, который многие понимают, как хотят.

Во Vue 3 у компонента есть, по большому счету, три варианта работы с внешними реактивными данными

1. Composable

Это технически (JS closure) и по факту (ООП) объект с данными и поведением. Компонент его создает, пользуется, при уничтожении компонента обнуляется ссылка на объект, и он подлежит уборке Garbage Collector-ом (GC).

2. "Модульный реф" / Pinia store

Тоже можно считать объектом в смысле ООП, но реализующим паттерн Singleton. Создается при первом вызове его кем-либо, затем ссылка на него записывается в некий глобальный реестр, и любой другой компонент, обращающийся к этой структуре, получает эту ссылку и работает с тем же самым инстансом.

3. Shared composable как в примерах в документации во VueUse и Vue

Рождается как стор, умирает как обычный composable. При первом обращении создается один объект, который затем используется всеми компонентами, которым он нужен. Но как только не остается ни одного такого компонента, этот объект "умирает". В дальнейшем если он понадобится, он создается опять в одном экземпляре.

Некоторые разработчики (не будем показывать пальцем) уверены, что использование shared composable именно как реактивного стейта вместо модульного рефа/стора помогает сделать программу эффективней.

Не обладая знаниями Мурыча, тем не менее давайте намного порассуждаем.

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

Как с shared composable? Вот он создается, используется, потом все компоненты, его использующие, кончаются - и он должен типа уничтожиться. Вызывается код по обнулению, но у Garbage Collector-а JS VM своя логика работы, и он не будет чистить эту память сразу. А если и будет - потратит на это ресурсы CPU. Затем снова появляется компонент, которому нужен этот объект - и он снова создается, тратятся ресурсы CPU, выделяется новая память. И так по кругу. В итоге, через 10 циклов у нас в куче памяти в 10 раз больше, чем нам надо, зарезервированного места, и мы потратили в десять раз больше ресурсов на создание/уничтожение структуры.

Так для чего нужен shared composable?

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

Таким образом,

состояние в shared composable выполняет не самостоятельную функцию, а является просто адаптером для некого внешнего сервиса / Web API.

И суть shared composable - создать единую реактивную точку доступа к внешнему сервису.

Даже чисто логически если подумать (по описанному выше юз-кейсу в пункте 3), то shared composable не может использоваться для непосредственного обмена данными между компонентами. Он может только передавать данные во внешний сервис, и получать их оттуда. Даже vueuse/useLocalStorage так работает. И если передача не удалась - это ошибка выполнения программы.

Но, опять же, если подумать, то данная логика (оптимизация работы с внешним сервисом) очень похожа на логику работы глобального лоадера. И реализована может быть так же в несколько строк, безо всяких effectScope и прочих заморочек - простым и понятным кодом. Нету там ничего из Composition API, что надобилось бы для реализации данной логики. Обычный модульный реф и синхронный код для отслеживания числа подписчиков с подключением/отключением этого рефа к внешнему сервису.

Ref, reactive, shallowRef, watch и computed должны покрывать 99.9% потребностей прикладного программирования на Vue.js. Не надо делать простое сложным.

Shared composable как он есть - изначально неудачное название и ненужная структура. Предлагается не использовать.

#composable #reactivity

Как же это близко...

Иногда хочется перед отправкой промпта встать на колени и сложить молитвенно ладони. Не потому что религия, а в качестве такого символического гагаринского "Поехали!".

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

#ai

Еще одно интервью Эвана о Vue, Vite, VoidZero и будущем JavaScript Tooling

#evanyou #video #interview

FilePond

Подсказали красивый file uploader компонент

15K+ звезд, много плагинов,, правда, довольно увесистый - 100Кб+

На JS. Подключается монтированием к элементу.

<script setup lang="ts">
import * as FilePond from "filepond";
import FilePondPluginFileValidateType from "filepond-plugin-file-validate-type";
import { onMounted, ref, useTemplateRef } from "vue";
import "filepond/dist/filepond.min.css";

const fileInput = useTemplateRef("fileInput");

FilePond.registerPlugin(FilePondPluginFileValidateType);

onMounted(() => {
  FilePond.setOptions({
    acceptedFileTypes: ["image/*", "application/pdf"],
    server: "api/upload/",
  });
  FilePond.create(fileInput.value);
});
</script>

<template>
  <div class="analysis-view">
    <h2>Analysis upload</h2>
    <p></p>
    <input
      ref="fileInput"
      type="file"
      class="filepond"
      name="filepond"
      multiple
      data-allow-reorder="true"
      data-max-file-size="3MB"
      data-max-files="3"
    />
  </div>
</template>

Вот, кстати, один из вариантов использовать динамические импорты/роуты - в мобильной версии drag-n-drop не нужен, поэтому можно обойтись более простым file input и сэкономить на бандле.

#lib

Довольно свежие Vue сниппеты для VS Code, среди большого количества хлама.

Vue 3 VS Code Snippets

#vscode #tip

Появление на фронтенде всевозможных фреймворков, методологий и прочей ереси - это woke-идеология

#esse

В команде Nuxt-а при выводе Nitro на внешний рынок внезапно осознали, что автоимпорты - плохо. И попытались их сделать опциональными. Но вход - рубль, выход - два.

Дело настолько деликатное, что ветку даже закрыли для просмотра посторонними.

Автоимпорты имеют существенные проблемы:
- не весь тулинг (IDE, Volar etc) их понимает, не всегда будут подсказки;
- код с ними выглядит гораздо менее явным, чем с обычными импортами в IDE;
- полная нечитабельность на площадках типа GitHub;

#goodpractices #nuxt

#tip #architecture #meme

Уже и индийские vue.js митапы идут.

Где в странах ex-СССР?

Московская тусовка, ау?

#event

Случайно нашел неплохой бесплатный хостинг для бэка

alwaysdata.net

До 100Mb, MySQL/PostgreSQL с портом наружу, PHP, Python, Ruby, Node.js, Elixir, Java, Deno, .NET , SSH, подключение кастомного домена

Год использую - всё ровно.

#webhosting

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

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

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

#vuefaq #learning #architecture #book

Сегодня - читальный зал

Белобров Попов
Груз ВКЖ-65

#offtop

Для реализации своих tooltip-ов и "выпадашек", наверное, самым оптимальный вариантом является использование современной и минималистичной библиотеки Floating UI

Их Vue адаптер мне не подошел. Вот простой вариант своего тултипа на их чистом js пакете.

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

Обертывать в Tooltip компонент то, на чем его надо показать, имхо, извращение.

<script setup lang="ts">
import { computePosition, flip, offset, shift } from "@floating-ui/dom";
import { onMounted, ref, useTemplateRef } from "vue";

const popover = useTemplateRef("popover");

onMounted(() => {
  popover.value.showPopover();
  computePosition(popover.value.parentElement, popover.value, {
    placement: "left",
    middleware: [flip(), shift({ padding: 5 }), offset(10)],
  }).then(({ x, y }) => {
    Object.assign(popover.value.style, {
      left: `${x}px`,
      top: `${y}px`,
    });
  });
});
</script>

<template>
  <div
    ref="popover"
    class="popover"
    popover
    role="tooltip"
  >
    <div class="tooltip-body">Hello</div>    
  </div>
</template>

<style scoped>
.popover {
  position: fixed;
  width: max-content;
  top: 0;
  left: 0;
  margin: 0;
  padding: 1em;
  text-align: left;
  border: 1px solid var(--bbl-c-border);
  border-radius: 5px;
  max-width: 400px;
  box-shadow:
    0 14px 44px rgba(0, 0, 0, 0.12),
    0 3px 9px rgba(0, 0, 0, 0.12);
  border-color: #bbb;
}
  </style>

#lib #tooltip #dropdown

Чтобы немного нейтрализовать психологическую травму, нанесенную TypeScript, вот на ночь четыре капли седатива от JS

#js

Автор русского перевода документации VitePress перевел и Vite документацию и просит сделать ревью его PR , чтобы его пропустили.

#vite #i18n

Вышел vue-router 4.5.0

Из примечательного - по инициативе Эвана на router-link появился prop view-transition, который задействует нативный View Transitions API для перехода между роутами.

<template>
  <RouterLink to="/some-page" view-transition>
    Go to some page
  </RouterLink>
</template>

Анимацию которого можно кастомизировать CSS стилями

Может быть быстрее вьюшного <Transition> и уж точно удобней в записи (по сравнению с конструкцией с router-view ). Но не такой функциональный, для простых переходов.

#router #animation #css

Неожиданно вышел Vite 6.0

Больших и даже просто значимых изменений практически нет. Предполагается, что это последний мажорный стабильный релиз перед заносом в Vite Rolldown-a и прочей Voidzero-шной машинерии.

#vite

Тут опросик замутили

Пишут, что уже несколько лет его проводят, но не попадался такой.

Эван, вроде, одобрил. Можно поучаствовать.

#vuejs #survey #stats

Вышел отчет State of Frontend 2024

Кроме того, что JQuery еще использует пятая часть опрошенных (а основная часть jq разрабов просто игнорирует подобные опросы), особо ничего интересного

#stats #survey