Vuex: доступ к магазину напрямую или мимо свойств?

Question

Я переношу чистое приложение Vue на Vuex, и я не уверен в лучшем способе передать данные компонентам вниз по течению. Путь Вью миновать их как свойства:

<component :my-prop="myProp"/> 

путь Vuex кажется, доступ к хранилищу напрямую:

computed: { 
    myProp: function() { 
     return this.$store.state.myProp; 
    } 
} 

ли не так Vuex, как правило, два мнения (компоненты) и слоты данных (хранилища) плотнее? С другой стороны, передача вниз вниз по течению может быть немного болью.

Каков рекомендуемый способ доступа к данным хранилища в Vuex?

Answer 1

Не уверен в «официальной» рекомендации, однако лично я предпочитаю использовать свойства. Таким образом, вы отделите компоненты от магазина. Например. ваши компоненты могут быть повторно использованы (в других проектах, позже и т. д.) и не имеют хранилища в качестве зависимости.

Если магазин когда-либо изменяется, например. новая версия VueX, другая лучшая практика позже, только родители должны измениться, все ваши компоненты будут вести себя одинаково.

Answer 2

Вам не нужно сохранять все в магазине vuex. У вас все еще есть данные компонента и передайте их дочерним компонентам через реквизиты.

Вот мой другой ответ на тот же вопрос для Redux:

Если государству не нужно делиться с другими компонентами, или государству не нужно держать, когда компонент размонтирования, то вы можете просто поместить его в состояние компонента.

Вы можете думать, что хранилище vuex является базой данных интерфейса, если у вас есть что-то вроде данных о продуктах, полученных из API, то хранилище vuex является правильным местом; если у вас есть компонент выпадающего списка, который будет принимать поддержку isOpen, тогда родительский элемент этого раскрывающегося списка может просто сохранить dropdownIsOpen как состояние компонента.

В принципе, это та же идея, у вас будет два вида компонентов, компонент контейнера и презентационный компонент.

Контейнерные компоненты напрямую получат доступ к хранилищу vuex; презентационным компонентам не нужно ничего знать о vuex, они получают только реквизит, поэтому их можно легко использовать повторно.

Answer 3

Как указано выше, получение данных в родительском объекте, а затем передача его как prop s может быть немного болью. Взамен этой боли мы получаем лучший дизайн, представьте ситуацию вроде этого: родительский компонент имеет несколько дочерних компонентов, он сам извлекает данные и передает данные детям. Здесь мы получаем «боль», заявленную ранее, но мы получаем: при изменении API данных мы можем редактировать только файл родительских компонентов, чтобы заставить его работать снова, детям не нужно изменять, пока родительский интерфейс подчиняется интерфейсу (event s и prop) между ними, которые мы ранее определяли. (Проще сравнить, если бы мы сделали ребенок, чтобы принести сами данные)

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

Кроме того, дочерние компоненты, которые мы обсуждали, получая реквизит, рендеринг самих себя, имеют вид pure function s, то есть выводят то же самое, если вводятся одинаково, но многократно повторяются. Как и то, что нам нравится в functional programming, они часто просты по форме, просты в обслуживании, но им нужно приложить дополнительные усилия и сначала написать их, чтобы адаптировать их к этому нечистому миру.