Мэйнтенер Volar Джонсон со своим помощником последние недели носятся с alien-signals - своей реализацией Signals в JS

Уверяют, что она самая быстрая, и пытаются встроить ее везде где могут - в системы стейт менеджмента для Solid.js, Dart, Lua. Движение unjs выходит за рамки js.

Пока наталкиваются на "непонимание".

Также хотят встроить ее во Vue. Эван, вроде, одобряет.

Но по поводу увеличения скорости на проценты хотелось бы спросить Эвана - зачем же он тогда перешел на js Proxy в своей системе реактивности и ухудшил производительность в десятки и сотни раз, если скорость так важна?

#vuejs #performance #reactivity

// useUserService.ts

function isAuthenticated() {
  return !!user.value;
}

// Component A

<script>
const { isAuthenticated } = useUserService();
</script>

<template>
  <p v-if="isAuthenticated()">hello</p>
</template>

Функции во Vue ведут себя не совсем как функции

В данном примере функция isAuthenticated() ведет себя как computed и будет вызываться каждый раз, когда user изменится или компонент А будет перерисовываться.

Происходит это из-за того, что Vue определяет все реактивные зависимости внутри тела функции и перерендивает компонент, когда кто-то из них меняется.

Таким образом, большой разницы в использовании функции вместо computed нет. Но если внутри большая логика, то лучше использовать computed, потому что он будет пересчитываться только когда его зависимости изменились, а функция - при любом рендеринге

#reactivity #tip #optimization

Написал статью "Обзор различных методов работы с реактивным стейтом во Vue"

Переделанная вот эта. Исправлены фундаментальные ошибки (автор не понимает, что такое composable функция) и некоторые другие недочеты

Внизу статьи опрос, просьба проголосовать.

Также размещено на Vue-FAQ

#reactivity #pinia #eventbus #article

Вышла вторая часть курса по Vue 3 Ильи Климова - "Реактивность"

Толковое объяснение "на пальцах". Яркий пример отличия учебника от документации.

Что не понравилось - смешивание понятия реактивности и связывания с шаблоном. Реактивные конструкции не приколочены к UI и могут использоваться и в других языках. Хотя, конечно, основное применение - динамичный пользовательский интерфейс.

#learning #klimov #rectivity

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

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

Если у вас есть массив, в каждом элементе которого есть computed, то лучше создать один на весь массив, чем много для каждого элемента

// Bad
const rows = productRows.map(row => ({
  ...row,
  total: computed(() => row.price * row.qty),
}));

// Good
const computedRows = computed(() => 
  productRows.map(row => ({
    ...row,
    total: row.price * row.qty,
  }))
);

#tip #performance #reactivity

Глубокое клонирование реактивных объектов в Vue 3

Vue 3 использует Proxy для реактивности, что создает проблемы при попытке клонировать объекты. Стандартные методы работают не так, как ожидается:

const state = reactive({ user: { name: "Al" } });

// Проблемы:
const badCopy1 = { ...state }; // сохраняет Proxy-ссылки
const badCopy2 = JSON.parse(JSON.stringify(state)); // теряет методы и Proxy

3 рабочих способа

1. Комбинация toRaw + structuredClone

import { toRaw } from 'vue';

const original = reactive({ data: 123 });
const copy = structuredClone(toRaw(original));

2. Ручное глубокое копирование

function deepClone(obj) {
  if (obj === null || typeof obj !== 'object') return obj;
  const clone = Array.isArray(obj) ? [] : {};
  for (const key in obj) {
    clone[key] = deepClone(obj[key]);
  }
  return clone;
}

const copy = reactive(deepClone(toRaw(original)));

3. Библиотечные решения

import { cloneDeep } from 'lodash-es';
const copy = reactive(cloneDeep(toRaw(obj)));

#tip #reactivity

Почему неконтролируемого использования watch лучше избегать?

1. Нарушение реактивного потока

watch часто скрывает логику реактивности. Например, отслеживание изменения переменной для вызова побочного эффекта (fetch) делает поток данных менее предсказуемым, особенно если эффекты затрагивают несколько компонентов.

Vue поощряет однонаправленную реактивность (данные -> шаблон). watch часто используется для обратной связи (данные -> данные), что усложняет отладку.

2. Плохая читаемость

Цепочки watch внутри компонента превращаются в плохо понимаемый в спагетти-код.

Плохо для рефакторинга - логика, разбросанная по watch, сложно переносится в composables.

3. Производительность

watch с deep: true может создать нагрузку при отслеживании больших объектов или массивов.

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

Неотписанные watch в динамических компонентах (например, внутри v-if) могут накапливаться и вызывать утечки памяти.


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

#reactivity #watch

На vue-faq.org я написал, что JS классы во Vue лучше не использовать. Это не совсем правильно. Не надо использовать классы с реактивными свойствами. Но если через классы создаются объекты без реактивности внутри, которые ты уже помещаешь в реактивные массивы - то вполне вариант.

Для диаграммы на картинке я попробовал сперва построить структуру объектов на TS, получилось громоздко и запутанно. Переделал на классы - стало намного читабельней и меньше кода. Ну и типизация настоящая (почти), а не эрзац. Так что теперь это основной вариант для сложных структур данных.

#oop #reactivity

const project = shallowRef(null as Project);

Как типизировать shallowRef ES классом

#reactivity

Можно обсудить AI генерацию

https://habr.com/ru/articles/920186/

#reactivity

Зачем Pinia, если можно написать свой стор?

Захотелось ответить на очень однобокий взгляд вот здесь - https://t.me/vuejs_ru_feed/37

Во-первых, это не велосипед, а решение под нужды своего проекта.

1. "Унификация и единый API". А давайте всех побреем и будем ходить строем. Сперва под Options API ходили, под Mixins API, под Vuex API, а теперь под Pinia API. Все, что было раньше и теперь на свалке, очевидно, было сразу плохо и временно, а вот Pinia API - это круто и навсегда, конечно

2. Нет, копию Pinia делать - это глупо. И никто это не делает. Надо решать задачи приложения, и без ограничений "единого API Pinia" они решаются проще, удобней, правильней и намного более функциональней при необходимости

3. Кроме ES модулей реализовать паттерн Singleton можно еще несколькими способами, если в этом есть необходимость по архитектуре приложения.

4. BFF SSR - зло и труп. Оставьте его врагам.

5. Какая-то надуманная проблема. Вы пишете сайты на десятки тысяч DOM элементов, а потом беспокоитесь, очистит ли GC покупательскую корзину, на которую [не] осталось ссылок?

6. А зачем очищать "глобальный стор"? Что под этим имеется ввиду, и как часто это надо делать? user = null; - это очищение стора? Свой стор не очищается при необходимости одной строчкой?

Еще раз, если у тебя в реактивных переменных столько данных, что они съедают значительную часть памяти веб-приложения и тормозят его - значит ты делаешь что-то не так. Эван для этого и придумал Reactivity API, возможности которого Pinia сильно обрезает.

И, нет, память это не освободит, а пометит для GC, который вряд ли на этом сработает в большинстве случаев.

7. Почему они должны быть объединены?

9. Реклама чужих велосипедов, таких же порой неправильных, тормозных и ненужных, как и во VueUse, в попытке сделать из Vue конструктор для вкатунов

10. Такое пишут люди, которые привыкли к Pinia и к её формату. Никаких проблем в работе в DevTools с обычными ("глобальными") реактивными переменными нет.

Ну и определять архитектуру приложения на основе своих предпочтений работы в DevTools - такое.

—

У не-Pinia решений есть плюсы. Ты не ходишь строем, а ходишь, как тебе удобно, используя в полной мере Vue Reactivity API.

—

На самом деле в оригинальном посте пропущен главный пункт, такой же как с Накстом:

11 . Когда в команде много слабо квалифицированных программистов, которые могут написать дичь, удобно всем ходить строем.

Ответ:

11. Повышайте уровень своих джунов до уровня проекта, а не опускайте проект до уровня джунов.

#pinia #reactivity