Всем привет. А я могу ref объявлять вне жизненных циклах

vue? Оно работает и не выдает ошибок, но не уверен, что так стоит писать.

можешь, это будет глобальный реф, который будет создан 1 раз при инициализации модуля если есть SSR, то это не будет работать

Не будет работать в том плане, что я на каждый реквест не смогу заинициализировать свой ref и у меня просто каждый реквест будет один и тот же реф дергать?

именно так, да

Понял, спасибо. Еще есть один вопрос последний: а так ли vue нуждается в state manager? С его реактивностью он выглядит самодостаточным. И мне кажется во многих случаях stm будет избыточен или это не так? Вопрос, наверное, сложный, можно просто да/нет ответить, чтобы я просто понимал, прав я или нет

в целом - да, во многих случаях он действительно избыточен, в большинстве приложений очень мало глобального стейта и при желании его можно расшарить и через условный provide/inject, просто сторы дают универсальный интерфейс, который все знают, ну и в дополнение всякие плюшки типа поддержки SSR и девтулзов но если приложение не особо сложное и над ним работает не целая команда, то можно без особых проблем обойтись provide/inject, просто это потребует чуть больше усилий по сравнению с готовыми сторами, где все уже есть из коробки

композаблы же удобнее provide/inject 🤓

композаблы не дают никакой дополнительной функциональности и не могут заменить provide/inject единственное, что там можно сделать - это вынести переменную в глобальный скоуп, но это не относится к самим композаблам и работает не во всех случаях

Где именно они не могут заменить provide/inject?

они вообще о разном

О разном То что может провад могут композаблы Но не наоборот

да там и нечем заменять, сами композаблы не дают ничего дополнительно, глобальный скоуп - это не про композаблы но если сравнивать с глобальным скоупом, то: - provide/inject умеет шарить данные между определенным куском дерева и только там, где его вызовут, а глобальный скоуп - синглтон по умолчанию - это не работает при SSR

не вспоминай про SSR при руслане :D

> работает не во всех случаях мне интересно что это за случаи

SSR

Глобальный скоуп это что? window.someVar - глобальный ref внутри модуля - модульный ref внутри композабл функции - локальный

в наксте например useState это же тот же композабл нет?

>ref внутри модуля - модульный модули инициализируются 1 раз, поэтому твоя переменная шарится по всему приложению и она одна, так что это самая настоящая глобальная переменная

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

> - provide/inject умеет шарить данные между определенным куском дерева и только там, где его вызовут, а глобальный скоуп - синглтон по умолчанию То есть правильно я понимаю, что дополнительная защита доступа (доступ имеют только потомки) - это и есть та фича, которая недоступна глобальным рефам?

глобальный реф не имеет представления об иерархии

т.е. злоупотребление композаблами грозит потерей иерархии?

где ты такое увидел

это не “защита доступа”, это принципиально другой механизм работы ты шаришь стейт только для поддерева, остальные компоненты не могут получить к нему доступ + ты можешь это сделать несколько раз в разных местах и при каждом провайде будет создаваться независимый стейт

независимый стейт можно сделать локальными рефами композабла

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

именно эту проблему и решает provide/inject

а на кой тебе в ногу стрелять если ты сразу можешь взять DI

Потому что когда логика метакомпонента вынесена в композабл, а в подкомпонентах только ихняя логика, тогда все намного лучше читается и осознается

DI никак не противоречит composable сколько раз я уже это написать должен

ок мне не попадались еще задачи чтобы providе/inject прямо так был к месту

provide/inject почти всегда и так заворачиваешься в композабл в провайдере вызывается что-то типа createSomeContext();, а в дочерних компонентах useSomeContext();

ну вот я как-то неделю назад кидал задачу про дропдаун, где нужно расшарить стейт между всеми дочерними элементами, чтобы не писать каждому v-model, - это отличное применение для provide/inject

я помню специфичная задача

для ui либ - практически стандартная)

Что значит независимый?

1 провайд - 1 переменная 2 провайда - 2 переменные каждая из них шарится на поддерево, они независимы

то что если есть 2 поддерева с провайднутым состоянием то они между собой никак не связаны

Если речь про то, что состояние не шарится, то композаблы тоже так могут

речь про то, что оно шарится на поддерево, а не “вообще не шарится” или “шарится для всех”

Тогда можно создать отдельное состояние (композабл), разве не так принято делать

композабл может работать только либо с локальной переменной, объявленной внутри композабла, либо с глобальной, объявленной за его пределами в первом случае ты получаешь локальный стейт, который остается в том же компоненте, где ты вызываешь композабл, и он никуда не шарится вообще во втором случае ты получаешь общий стейт на все приложение, любой твой компонент будет работать только с ним и ни с чем больше это не то же самое, что и provide/inject

по факту композабл из коробки умеет ничего :D

так и есть, это просто кусок компонента

Ты говорил, что стор лучше заменить provide inject,чем это лучше композаблов? Тут различие о шаринге только внутри дерева ничего не дает

ref в модуле это не кусок компонента

композаблы сами по себе ничего шарить не умеют вообще, это не замена provide/inject ты можешь расшарить только глобальную переменную, но, как я писал выше, это не будет работать с SSR и ты не сможешь создать несколько инстансов этой переменной, если потребуется

так ref в модуле и к композаблам никак не относится

а чем композабл отличается от модуля с рефом и функцией внутри?

Можешь пояснить, что такое инстанс переменной? А то что композаблы сами по себе не могут шарить данные, только если переменная объявлена в глобальном скоупе все ещё не мешает шарить стейт глобально

а что отличает комозабл от обычной функции?)

тем, что композабл может работать с компонентным апи и вызывать внутри себя onMounted, inject, watch и все остальное, что привязано к жизненному циклу компонента

ну куда ты ответ так сразу :D

ну так если он это не использует, какой он кусок компонента? а во-вторых, это просто хуки, которые он позволяет дергать, если они есть

это количество копий этой переменной если ты объявил 1 глобальную переменную, то она так и остается одной и ты не сможешь просто создать ее независимую копию без костылей с фабриками в случае с provide/inject ты можешь создавать сколько угодно копий твоего стейта и они все будут независимые

Ну я же говорю в контексте глобального стейта( стора ), он на то и глобальный

если говорить о глобальном то это не реакт, и тут стора подойдет лучше

разве я не могу вызвать его из простого модуля?

так я и говорю, что да, так можно, но: 1. ты не сможешь создать несколько инстансов 2. это не будет работать с SSR если оба пункта не проблема, то можно использовать глобальную переменную и шарить ее через композабл

Стор зачастую overkill, то же самое можно и с композаблами сделать, просто стор даёт готовый апи

твой глобал реф это тоже стор

можешь, но часто ли ты так делаешь и часто ли это нужно?

Теперь стало на свои места, но остался ещё один вопрос, как изменять стейт из потомков?

Зависит от архитектуры приложения Еще раз - я смотрю на композаблы как на реактивные классы/объекты, в которые при необходимости можно засунуть бизнес логику, не привязанную к компонентам

через функцию, которую провайдит родитель

Так я про это и говорю

На каждую мутацию провайдить функцию?

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

а обычно много чего нужно мутировать из дочерних компонентов? + стейт можно группировать и одной функцией менять любое свойство

Provide inject в качестве альтернативы стора звучит неплохо, но видимо я просто не представляю кейс когда нужны инстансы переменных в глобальном стейте и поэтому подумал что это идея ужасна

конкретно для глобальных сторов это обычно не нужно, там всегда 1 инстанс на все приложение, но для других случаев вполне себе бывает нужно ну и, опять же, provide/inject может быть альтернативой глобальному стору, но это не всегда рационально и часто приводит к велосипедам я бы его брал в качестве стора только в самых простых случаях, когда нужно что-нибудь быстро расшарить на все приложение

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

с этим я и не спорил, а как раз объяснял, что provide/inject именно для таких случаев и нужен, а пытаться имитировать это через композабл - мягко говоря, неудобно