Комментарии 22
А зачем делать геттеры для простых свойств? Я всегда считал, что во Vuex геттеры нужно применять для сложных объектов
В статье мы наблюдаем демонстрацию того, что это возможно при использовании Vuex.
сегодня это простое свойство, завтра уже композиция, а послезавтра рефакторинг и куча проблем. Весь это простой на первый взгляд flux подход скатывается в снежный ком проблем по мере увеличения проблем, так что лучше гибкость закладывать заранее.
В коде из раздела «Но почему?» ошибка в действии «SET_NAME»:
Тут должно быть не
context.dispatch('SET_NAME', name);Тут должно быть не
dispatch, a commit — иначе получается какая-то рекурсия.Геттеры используются для доступа к значениям, находящимся в хранилище.Даже в официальной документации Vuex сказано что геттеры следует использовать только для производных данных, основанных на состоянии.
Зачем для хранения данных использовать Vuex (самому писать геттеры, сеттеры, даже для простейшего получения значения и установки значения) если есть localStorage. Почему не использовать localStorage для хранения данных?
Будет ли работать реактивность в случае с использованием localStorage?
Ну во первых изменение состояние Vuex автоматически вызывает изменения в DOM, а в LocalStorage отследить состояние можно только отследив событие «storage», причем это событие не сработает если оно вызвано кодом исполняемым в той же вкладке.
Во вторых в LocalStorage можно хранить только строки, а чтобы поместить туда хотябы простейший объект — его надо сериализовать.
В третьих localStorage сохраняет свои данные после закрытия вкладки и обновляет свои данные сразу во всех вкладках, в которых открыт сайт, а это далеко не всегда нужно.
Ну и еще много причин. Если в кратце — то это разные механизмы, предназначенные для разных задач и заменить одно другим нельзя.
Во вторых в LocalStorage можно хранить только строки, а чтобы поместить туда хотябы простейший объект — его надо сериализовать.
В третьих localStorage сохраняет свои данные после закрытия вкладки и обновляет свои данные сразу во всех вкладках, в которых открыт сайт, а это далеко не всегда нужно.
Ну и еще много причин. Если в кратце — то это разные механизмы, предназначенные для разных задач и заменить одно другим нельзя.
А я все жду, когда же они разродятся вот этой фичей из роадмапа:
Simplify usage
- Getting rid of mapXXX helpers via scoped-slot based store consumer component
- Getting rid of the need for separating actions and mutations
«Посмотрите на Redux, а теперь на Vuex, снова на Redux и снова на Vuex. Да, Vuex на коне!»
заголовок статьи не соответсвует содержанию, в статье изложен только базовый функционал, например про модули сказано что они есть и все
при попытке сохранить (через мутацию) в стейте компонент получаем кучу мата о том, что содержимое компонента изменяется не через мутации. Как обойти?
Передача данных в магазин :) Переводчик даже не старался. Спасибо.
Сразу смотрите vuex-module-decorators. Облегчит жизнь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Освоение Vuex — с нуля до героя