а из одного дочернего в другое?

Сразу вопрос. Зачем городить хранилище, мутации и прочее если с потока можно просто дергать при желании последнее значение. Чем это выгоднее?

vuex управляет состоянием приложения. Какая вкладка открыта, какой компонент отображается, как именно отображается тот или иной компоненет, как изменить отображение в зависимости от тех или иных действий пользователя, активна кнопка или нет и т.д. Мутации и Экшены нужны в свою очередь для того, чтобы сделать все изменения управляемыми, инкапсулировать состояние и предоставить простой единообразный способ управления всем этим, в том числе и мощный инструмент отладки А основная проблема, которую решают потоки - это конкуренция в асинхронном програмированнии. Скажем, тебе нужно организовать текстовый поиск, при котором происходит запрос к удаленному серверу, можно потратить минут 10 описывая это через колбеки, вводя дополнительные состояния, чтобы запросы передавались не чаще, скажем, одного раза в 2 секунды, чтобы запросы не передавались, если данные поля не изменились, и еще пара проверок, и все это будет крайне утомительно, если не сказать болезненно. С помощью rxjs эта совокупность проблем решается в несколько строк кода. Разные задачи у vuex и rxjs.

vuex управляет состоянием приложения. Какая вкладка открыта, какой компонент отображается, как именно отображается тот или иной компоненет, как изменить отображение в зависимости от тех или иных действий пользователя, активна кнопка или нет и т.д. Мутации и Экшены нужны в свою очередь для того, чтобы сделать все изменения управляемыми, инкапсулировать состояние и предоставить простой единообразный способ управления всем этим, в том числе и мощный инструмент отладки А основная проблема, которую решают потоки - это конкуренция в асинхронном програмированнии. Скажем, тебе нужно организовать текстовый поиск, при котором происходит запрос к удаленному серверу, можно потратить минут 10 описывая это через колбеки, вводя дополнительные состояния, чтобы запросы передавались не чаще, скажем, одного раза в 2 секунды, чтобы запросы не передавались, если данные поля не изменились, и еще пара проверок, и все это будет крайне утомительно, если не сказать болезненно. С помощью rxjs эта совокупность проблем решается в несколько строк кода. Разные задачи у vuex и rxjs.

Зачем сохранять активность кнопки, отображение компонента или еще какие-то view ориентерованные данные во vuex?

Когда писал, мне показалось излишним городить абстракцию в духе: vuex хранит данные, которые в свою очередь определяют как отображать view.

Вот подобная ситуация меня и смущает.

@sergeykhorn Мне интересно другое, в чем идея хранить так много данных в сторе, почему не локальный стейт умных компонентов?

В Краснодаре

о, земляк)

а говорят тут программистов мало

Меня смущает непомерное раздувание количества всех этих мутаций по пустякам.

я пока не проьбовал искать, как переехал сюда работу не менял, так и работаю в своей старой фирме, только теперь удаленно

Штука вот в чем, допустим у тебя есть компонент "Аватарка", у которой есть два состояния: скругленные края и острые, она расположена глубоко в дереве компонентов. Так же есть компоненты "Кнопка", который находится столь же глубоко, но не является ни родителем, ни потомком компонента "Аватарка". Для того, чтобы эта "Кнопка" по нажатию переключала внешний вид "Аватарки" она должна генерировать событие для своего родителя, тот для своего, и так до ближайшего общего родителя, который в свою очередь будет прокидывать в цепочку до "Аватарки" props передаваемый "Кнопкой". И генерацию событий, и передачу свойств прийдется описывать ручками в каждом компоненте. С помощью vuex, все это происходит практически автоматом в пару строк кода. Вот и получется, что вместо ручной синхронизации всего и вся, проще использовать vuex, чтобы сотояние было общее для всего приложения.

вот ты не ленивый)

Я только учусь, потому объясняя часть знаний закрепляю, часть переосмысливаю.))

Штука вот в чем, допустим у тебя есть компонент "Аватарка", у которой есть два состояния: скругленные края и острые, она расположена глубоко в дереве компонентов. Так же есть компоненты "Кнопка", который находится столь же глубоко, но не является ни родителем, ни потомком компонента "Аватарка". Для того, чтобы эта "Кнопка" по нажатию переключала внешний вид "Аватарки" она должна генерировать событие для своего родителя, тот для своего, и так до ближайшего общего родителя, который в свою очередь будет прокидывать в цепочку до "Аватарки" props передаваемый "Кнопкой". И генерацию событий, и передачу свойств прийдется описывать ручками в каждом компоненте. С помощью vuex, все это происходит практически автоматом в пару строк кода. Вот и получется, что вместо ручной синхронизации всего и вся, проще использовать vuex, чтобы сотояние было общее для всего приложения.

с темпом развития темы, "учимся" мы постоянно))

Штука вот в чем, допустим у тебя есть компонент "Аватарка", у которой есть два состояния: скругленные края и острые, она расположена глубоко в дереве компонентов. Так же есть компоненты "Кнопка", который находится столь же глубоко, но не является ни родителем, ни потомком компонента "Аватарка". Для того, чтобы эта "Кнопка" по нажатию переключала внешний вид "Аватарки" она должна генерировать событие для своего родителя, тот для своего, и так до ближайшего общего родителя, который в свою очередь будет прокидывать в цепочку до "Аватарки" props передаваемый "Кнопкой". И генерацию событий, и передачу свойств прийдется описывать ручками в каждом компоненте. С помощью vuex, все это происходит практически автоматом в пару строк кода. Вот и получется, что вместо ручной синхронизации всего и вся, проще использовать vuex, чтобы сотояние было общее для всего приложения.

В целом я понимаю почему общий стейт выгоден и оправдан. Читал историю возникновения всех этой Flux архитектуры. Меня смущает что для каждого скругленного уголка в хранилище нужно делать мутацию, которая перезаписывает весь обьект с потрохами. И допустим у нас есть кучка статей и хнранятся они у нас в массиве, нужно поменя их свойство прочитаны они или нет, ведь приходится копировать весь массив потом менять что нужно и записывать обратно. Или я что-то упускаю? Это вобще по памяти эффективно?

Да такие изменения стейта я тоже выношу в стор on demand. Я просто подумал что ты все изменения стейта выносишь во vuex.

Тогда на всякий случай отмечу, что всё подряд в лобалстейте типа вьюекса хранить не стоит. Если есть логика в том, чтобы от него зависело отображение, то лучше "прокидывать" события

Ну, это очевидно массив объектов, которые передаются в свою очередь по ссылке, и тут мутации будут не перезаписывать state, а менять свойство объекта статьи. Так вроде.

Есть изящные методики как в этом всем не потеряться? Воркфлоу какой нибудь может. Типа чтобы глянул такой на компонент и сразу видно что да где куда пуляется и принимается

Штука вот в чем, допустим у тебя есть компонент "Аватарка", у которой есть два состояния: скругленные края и острые, она расположена глубоко в дереве компонентов. Так же есть компоненты "Кнопка", который находится столь же глубоко, но не является ни родителем, ни потомком компонента "Аватарка". Для того, чтобы эта "Кнопка" по нажатию переключала внешний вид "Аватарки" она должна генерировать событие для своего родителя, тот для своего, и так до ближайшего общего родителя, который в свою очередь будет прокидывать в цепочку до "Аватарки" props передаваемый "Кнопкой". И генерацию событий, и передачу свойств прийдется описывать ручками в каждом компоненте. С помощью vuex, все это происходит практически автоматом в пару строк кода. Вот и получется, что вместо ручной синхронизации всего и вся, проще использовать vuex, чтобы сотояние было общее для всего приложения.

И тогда при записи arr[12] = 13 не будет реактивности

Что-то я потерялся. Ты ведь это делаешь не через мутацию.

Есть изящные методики как в этом всем не потеряться? Воркфлоу какой нибудь может. Типа чтобы глянул такой на компонент и сразу видно что да где куда пуляется и принимается

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

Ну у меня почему то вышло в основном что 50% мутаций это тупо запись какой нибудь штуки в стейт. Потому это меня и засмущало. Я с ангуляра первого просто приехал, может сказываются старые привычки просто.

а как должно быть?)

тебя негры оттуда засудят

какая-то компонента из последних, возможно, коммитов

И мнение @Fl0pZz что тут он не нашёл бы работу я не разделяю. С его-то опытом

Угадай, какой к меня опыт сейчас

я думаю ты мидл. Как бы не обидеть)