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

Но потом жди мата и ругательств от такой неявной штуки

пока-что реализова в руте... думаю: $root.__uic_scrollable_nativeScrollbarWidth не должно создавать конфликтов с юзерским кодом

слишком рандомное название

потому-что это во первых ну НИЧЕМ не отличается от root'а, во вторых это ОБЯЗЫВАЕТ пользователя компонента ставить Vuex, только ради сраной статичной переменной?

вообще как бы отличается)

вообще как бы отличается)

требовать Vuex ради, извиняюсь, сраной переменной... это маньячество

требовать Vuex ради, извиняюсь, сраной переменной... это маньячество

Ну он и не для этого, да.

вообще как бы отличается)

однако, Vuex это всего лишь замена $root которая обезопасывает мутации Vuex.state это такой-же $root с точки зрения глобальных переменных, коллизию с пользовательским кодом не избежать, можно лишь сделать её менее вероятной рандомизировав название переменной

но если разработчику приложения использующему данный компонент взбредит в голову назвать какую либо переменную своего приложения именно: "__uic_scrollable_nativeScrollbarWidth" то неизбежно бомбанёт

однако вероятность низка. Кстати вероятность коллизии именно в $root даже ниже чем в Vuex, поскольку (надеюсь) никто не использует $root для application state management'а, а вот Vuex засорять уж точно не надо

не будет коллизий в $root, так будут коллизии в Vuex.state, что гораздо хуже

Коллизии не будет во Vuex если поставить флаг namespaced: true

Коллизии не будет во Vuex если поставить флаг namespaced: true

а, так в Vuex есть пространства имён? прикольно, не знал. Но тем не менее не повод требовать зависимости Vuex ради одной глобальной переменной

а, так в Vuex есть пространства имён? прикольно, не знал. Но тем не менее не повод требовать зависимости Vuex ради одной глобальной переменной

Согласен. Ради одной переменной устанавливать вьюекс. Это было к сведению. Почему бы тебе не использовать замыкание в отдельном файле для твоей задачи?

Согласен. Ради одной переменной устанавливать вьюекс. Это было к сведению. Почему бы тебе не использовать замыкание в отдельном файле для твоей задачи?

не совсем понял что ты имеешь ввиду, замыкание в отдельном файле?

не совсем понял что ты имеешь ввиду, замыкание в отдельном файле?

Тебе нужна переменная которая будет доступна для других компонентов и они могут ее значение получать/мутировать. Я тебя правильно понял?

Тебе нужна переменная которая будет доступна для других компонентов и они могут ее значение получать/мутировать. Я тебя правильно понял?

нет, переменная должна делиться между инстанциями определённого компонента

Она статичная

верно

точнее, не "константная", ибо она вычисляется в момент инициализации инстанции компонента, а именно статичная (static class field)

верно

Создай файл: export const staticValue = 1

Создай файл: export const staticValue = 1

это константная, не статичная

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

чтоб первая инициализация установила переменную, а последующие просто её считывали

это константная, не статичная

Тогда можно создать по шаблону revealing module pattern

что я сейчас и делают в root

С геттерами и сеттерами

Никто не сможет смутировать ее случайно

Она живет своей отдельной жизнью в своем файле

Все твои требования исполняет

Рут, вьюекс не засоряешь

хмм, ща загуглю

Тогда можно создать по шаблону revealing module pattern

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

мерси!

мерси!

Не проблема

Ребята, разбираю сурсы одного проекта.

Что есть get?

Это computed так вынесено или что это?

Почему так оформлено?

Что есть get?

это геттер из es5

Я просто в JS не так давно зашел.

Поэтому путаюсь в разных редакциях.

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

А как лучше написать?

первое - добавить кеширование

Вот например нижний геттер. Нахрена вообще его так оформлять?

второе, действительно вынести в computed

+ насчет computed

А добавит ькеширование это чо зачит?

Вот например нижний геттер. Нахрена вообще его так оформлять?

он просто хотел сделать привязку к this конкретного объекта

чтобы не передавать id items как параметр

точнее чтобы впринципе не добавлять id 🤷‍♂️

странное решение конечно

И ни одного комментария, поясняющего эти странные решения)

А если в компьютед также вынести этот подсчет суммы общей, исходя из элементов массива.

А добавит ькеширование это чо зачит?

это значит, что пересчитывать get total_price не при каждом запросе, а только при изменении

Или чо там есть еще watch.

и в сулчае использования computed тебе вообще не придется выполнять этот пунтк

Они с computed как раз этим и отличаются же?

Что воч каждый раз делает.

А компьютед думает.

Они с computed как раз этим и отличаются же?

нет, там разница идеологическая: computed - когда тебе важен не только факт изменения значения, но и новое значение вотчер же нужен только есть тебе нужен сам факт изменения значения, но на значение, можно сказать, пофиг

Ну в воче все равно можно вычислять значение. =)

Просто это костыль и неправильно.

Ну в воче все равно можно вычислять значение. =)

перечитай мое сообщение, плз

вотч это как обсервер

Ну я перечитал да.

он наблюдает за значением

Но он же обсервит и потом какое-то действие предпринимает все равно.

и вызывает какой то коллбек когда значение меняется

Ну я перечитал да.

ну ты понял что ни тот ни тот не является никаким костылем?

Ну всмысле, что реализовывать через воч то, что реализуется через компьютед — костыль.

еще раз перечитай мое сообщение

как ты собрался через watch реализовывать то что реализуется через computed ?)

И ведь перечитал. =)

как ты собрался через watch реализовывать то что реализуется через computed ?)

просто интересно

Да я и не собрался пока.

Просто компьютед я юзал, а воч нет. =)

И поэтому пока нету понимания.

Но я стараюсь. Почитаю еще раз документацию.