Жил был разработчик. Писал он себе кодяру на Vue.js и горя не знал, пока черти не дернули его более внимательно прочитать доку по VUEX. И увидел он там волшебное слово FLUX.
Обычно при разработке приложений придерживаюсь принципа:
- Все данные которые относятся непосредственно компоненту храним непосредственно в нем
- Global/Shared данные в стор
- Как вариант разделать stateless и stateful компоненты
На пример у нас есть простенькая страничка со списком айтемов и нам необходимо его отрисовать. Я создаю компонент pages\news\NewsPage.vue и pages\news\NewsItem.vue.
В первом обращаюсь к АПИ, сохраняю список айтомов, меняю статусы(loading/error). Все в одном компоненте(файле). Второй принимает через проп айтем и отрисовывает его. Все! Далее для дебага юзаем как обычно VueDevTools и не знаем горя.
Но у FLUX'а на эту задачу немного другой ответ. И так рассмотрим тот же пример с двумя компонентами. Для реализации данного ф-ционала нам понадобится взаимодействовать с пятью абстракциями:
- State module store
- Action
- API call
- Mutation
- Getter
В action через api call фетчим данные >> записываем данные в стор через mutation. При этом зачастую для каждой сущности(доменной группы сущностей) в сторе создается отдельный модуль и в каждом модуле лежит 4-5 js файлов (actions.js, mutations.js ...).
Для фетча данных выходит такой путь DISPATCH >> ACTION >> API_CALL >> MUTATION >> GETTER. Для отображение какого нибудь loading статуса, необходимо пройти$store >> someModuleState >> loading ну да или воспользоваться вспомогательной ф-цией mapState. Вместо this.loading. А как быть с формочками тоже прикажите хранить эти все чекбоксы/инпуты в сторе ?
При таком раскладе каждый разработчик трактует по своему как разделять данные. Это в стор/это в локальное состояние компонента. У каждого свой FLUX.
А все это делается что бы придерживаться принципа одностороннего изменения данных. Компонент не должен знать как менять данные итд. Что в итоге деет свои плюшки при поддержке и дебаге приложения. А если сюда еще добавить еще и функциональщину и иммутабельность... все ховайся... А по факту в большинстве случаев(я не обобщаю.) все как дебажили консоллогом так и дебажат. Периодически заглядывая в VueDevTools.
В контексте React приложений своя атмосфера и оно там к месту.
- К месту ли такие танцы в контексте Vue ?
- Стоит ли овчинка выделки ?
- Как понимать что хранить в сторе а что в локальном состоянии компонента ? Статусы (error/loading), филды формочек, чекбоксы... это все куда ?
Если вам есть что сказать буду рад обсудить в комментах.
p.s.
- Знаю холивар
- https://github.com/zmts/beauty-vuejs-boilerplate
https://ru.vuejs.org/v2/guide/state-management.html
Перечитав доку пришел к такому выводу:
Одним из основных задач FLUX есть централизация управления состояния приложения(single source of truth). Например есть у нас сущность
news. В сторе создаем соотвествующий модуль, в нем описываем все взаимодействия сущности с приложением в том числе и запросы к АПИ. В итоге имеем ЕДИНУЮ точку управления сущностью.Для примера если у нас страничка Новости размазана по 10ти компонентам вместо того чтобы описывать кучу методов/апиколлов в каждом компоненте(ну или почти каждом) при необходимости мы обращаемся к ЕДИНОЙ точке изменения состояния к модулю
newsв сторе.Еще раз но иными словами.
Есть у нас страничка Новости (сущность
news). Она состоит из 10 компонентов. В части этих компонентов описываются апиколлы/методы/геттеры. В общем к каждом компоненте свой набор методов. FLUX предлагает создать для сущностиnewsсвой модуль в сторе и там описывать все апиколлы/методы для данной сущности. Повторюсь таким образом мы не распыляем по компонентам бизнес логику а централизованно держим в одном месте.