Непонятно, с какого момента композаблы стали называться сторами Вроде они были

"продолжением" компонент
Эван Ю знает, что это теперь сторы?

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

Когда я говорю о композабл функциях, то я имею ввиду стейт за пределами функций, если явно не указано иное Когда из такого композабла делают useAuth - это стор?

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

1. Это классический пример из доки 2. Композабл возвращает не саму переменную, а компьютед или функцию isAuthenticated() Так это стор? По определению Пиньи

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

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

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

руслану противопоказано писать про сср :D

an entity holding state and business logic that isn't bound to your Component tree Причем тут ССР, свое апи и эдж кейсы?

ждем бота, который будет ловить упоминания “SSR” и кидать ссылку на страницу про тупиковую ветвь во фронтенде хотя я с этим даже согласен

Я что-то говорил плохое про ССР в этой или других дискуссиях тут последние три дня?

SSR при том, что пиния его поддерживает и не ломается, а глобальная переменная в модуле будет шариться между всеми клиентами свое апи при том, что недостаточно объявить в 1 строку глобальную переменную и обозвать ее стором, разве что только очень условно эдж кейсы при том, что, опять же, стор - это нечто большее, чем 1 строка с объявлением переменной и есть много “но”, которые нужно решать и они решены в пинии

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

Я хотел сказать что мое отношение к ssr никак не влияет на дискуссию про сторы

прямо влияет так как это причина почему многие не могут перейти на твое решение в связи с тем что им нужен SSR

отношение - да, но сам SSR тут имеет место быть

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

да, если включен SSR, то стейт расшарится на всех клиентов, это актуально не только для накста, но и для любого самописного SSR у них там есть отдельный useState (https://nuxt.com/docs/getting-started/state-management#best-practices), но я не особо изучал, что конкретно он у них делает, но точно знаю, что он умеет в сериализацию но в общем случае просто нужно использовать provide/inject или стор, если нужно что-то расшарить глобально или на какое-то поддерево

ну да, по факту через useState тоже можно расшарить данные, так что для накста этот вариант наиболее актуальный, наверное https://nuxt.com/docs/getting-started/state-management#shared-state

Во дела