Vuex - это глобальная библиотека для управления состоянием.
Ранее видел очень много разработчиков, которые не правильно используют Vuex. То есть, они управляют состоянием которое в действительности не являлось глобальным через Vuex.
Что же это значит?
Например:
Форма списка имела бы свой отдельный Vuex-модуль который управляет не только добавлениями и редактированиями, но и API Request(getData/sendData). Используя такой подход мы распространили бизнес-логику по всему приложению, вместо этого следовало бы инкапсулировать бизнес-логику в дерево компонентов.
На самом деле такая проблема простительна, но только в небольших проектах где модулей немного. Но, если это большой проект, то соответственно у вас будет больше десятка модулей и за ними всеми уследить будет сложно, а уж рефакторить - вдвойне.
Рассмотрим пример:
Используйте Vuex для реальных глобальных задач, допустим: данные о пользователе, конфигурация приложения.
Про наименования:
Про state:
- Создайте файл с константами и работайте с ними допустим:
Про геттеры:
- Не используйте геттеры там где они не нужны(видел очень много такой bad-practice). Например: геттер возвращает объект из state. К примеру: getUser. В таких случаях лучше напрямую обращаться к state и вернуть этот объект.
Про map(state/getters...):
- В небольших проектах это не проблема, но кто вам сказал, что ваш проект не станет большим? Поэтому сразу начинайте правильно работать с данными.
Про мутации:
Позже дополню еще, оцените статью и дайте обратную связь.
Дайте понять, про что вы еще хотите услышать, чем больше ответов - тем больше мотивации сделать следующие мануалы
Ранее видел очень много разработчиков, которые не правильно используют Vuex. То есть, они управляют состоянием которое в действительности не являлось глобальным через Vuex.
Что же это значит?
Например:
в приложении есть функция которая позволяет пользователю создать и редактировать список покупок.
Форма списка имела бы свой отдельный Vuex-модуль который управляет не только добавлениями и редактированиями, но и API Request(getData/sendData). Используя такой подход мы распространили бизнес-логику по всему приложению, вместо этого следовало бы инкапсулировать бизнес-логику в дерево компонентов.
На самом деле такая проблема простительна, но только в небольших проектах где модулей немного. Но, если это большой проект, то соответственно у вас будет больше десятка модулей и за ними всеми уследить будет сложно, а уж рефакторить - вдвойне.
Рассмотрим пример:
Однако, самое главное правило при работе с глобальной библиотекой управления состояния - Не использовать ее для всего.Проблемы: Vuex становится сложнее понять, какие части приложения используют те или иные модули, и разработчики могут даже бояться рефакторить любой из них, потому что никто не знает. Какая часть приложения может пострадать/сломаться
Используйте Vuex для реальных глобальных задач, допустим: данные о пользователе, конфигурация приложения.
Про наименования:
- Не создавайте названия которые понятны только вам. Через неделю и вам будет непонятно. Представьте, что вы открываете папку "modules", а там: list, status, compare.
- Вам это дало какую-то информацию? Надеюсь, что вам оно тоже ничего не дало)). Бест практика: user, products, appConfig. Тоже самое относится: геттерам, state, mutations, actions
[*]Значение items в state, вам оно дало какой-то смысл? Конечно нет, а как насчет? productCategories, products. Согласитесь стало лучше?
[*]Если состояние возвращает булевое значение, лучше в начало добавить "is". Пример: isAuthUser. isAdmin
[*]Если состояние возвращает объект/массив лучше всего писать с добавлением "get". Например: getProducts, getAdvances.
[*]Если состояние что-то мутирует лучше добавить: set, add, remove. Где set - установка нового значения, add - добавление нового значения, remove - удаление значения
Про state:
- Создайте файл с константами и работайте с ними допустим:
import * as types from "./types.js"
mutations: { [types.INCREMENT](state) { state.count++ } }
Про геттеры:
- Не используйте геттеры там где они не нужны(видел очень много такой bad-practice). Например: геттер возвращает объект из state. К примеру: getUser. В таких случаях лучше напрямую обращаться к state и вернуть этот объект.
Про map(state/getters...):
- В небольших проектах это не проблема, но кто вам сказал, что ваш проект не станет большим? Поэтому сразу начинайте правильно работать с данными.
import mapGetters from "vuex";
{ computed: { ...mapGetters({ getUser: userTypes.getUser }) } }
Про мутации:
- Хорошей практикой является написание мутаций верхним регистром. (в реализациях Flux. Vuex основан на архитектуре Flux).
- Не создавайте лишний код в мутациях. Задача мутации - мутировать данные из state. Мутации не должны ничего кроме этого делать. ( ВООБЩЕ НИЧЕГО!! ), если вам нужно сделать какие-то действия, то используйте actions и внутри вызовите commit когда это нужно будет!
- Не мутируйте state напрямую!! Это очень плохо для мутации хралища и есть mutations!!!
Позже дополню еще, оцените статью и дайте обратную связь.
Дайте понять, про что вы еще хотите услышать, чем больше ответов - тем больше мотивации сделать следующие мануалы
Последнее редактирование: