Стоит ли использовать vuex mapGetters? - PullRequest
Новая
       40

Стоит ли использовать vuex mapGetters?

0 голосов
/ 12 октября 2018

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

Это также означает, что ваш компонент теперь специально привязан к Vue, что еще одна вещь, с которой нужно бороться, если вы перенесете компоненты на другую инфраструктуру, такую ​​как React.

Рассмотрим эти 2 списка вычисленных свойств: 

import { mapGetters} from 'vuex'
    computed: {
        ...mapGetters({
          active:'interface/active',
          mode:'interface/mode',
          views:'interface/views',
        }),
    }

против 

computed: {
      active:() { return this.$store.getters['interface/active'],
      mode:{ return this.$store.getters['interface/mode']},
      views:{ return this.$store.getters['interface/views']},
}

Конечно, последний немного более многословен, но ничего слишком плохого.Вы по-прежнему получаете все свои данные геттера одинаково в любом сценарии.Быть таковым кажется совершенно ненужным пухом для небольшого преимущества сохранения нескольких символов.

Первый пример весит 207B (201 символ)

, в то время как последний пример весит 207B (201 знак).

Для меня это означает с точки зрения типасбережений практически нетОднако я признаю, что первое более читабельно, портативно и, в конечном счете, проще в обслуживании, поскольку ваши релевантные данные находятся в одном месте.

1 Ответ

0 голосов
/ 13 октября 2018

Я думаю, что здесь стоит упомянуть пару вещей, касающихся вашего мнения о вспомогательной функции, например mapGetters

  • О вашем коде, тесно связанном с vuex если вы решите импортировать mapGetters: следует уточнить, что подход, при котором вы непосредственно получаете доступ к this.$store.getters, не делает ваш код менее связанным с vuex.В конце концов, такой прямой доступ уже предполагает довольно много о функциональности store и о том, как они работают с компонентами.

    Возьмем предоставленные вами фрагменты в качестве примеров, уже можно видеть, что реализация вашего магазина a) имеет концепцию, называемую getters, и b) поддерживает модули так, что вы можете определить модуль interface, как вы это сделали.

    Предположим,однажды, вы как-то решите переключить реализацию store на что-то вроде puex, которая абсолютно не имеет понятия ни getters, ни modules, вам придется реорганизовать все 3 объявлениятем не мение.Или даже если вы решите переключиться на что-то более продвинутое, например Flure, это также поставит вас в аналогичную ситуацию: хотя у Flure есть концепции геттеров и модулей, они не отображаются одинаково vuex делает, поэтому вам нужно отредактировать все 3 строки (снова).

    Не говоря уже о переносе в React, код, который вы имеете в вычисляемых свойствах, даже не будет переносимым в другие библиотеки хранилищ, созданные специально для Vue.Так что, на самом деле, вам не стоит слишком беспокоиться об использовании mapGetters.

  • Во-вторых, для экономии типов, если вы не собираетесь переименовывать эти свойства, вашmapGetters вызов на самом деле может быть сокращен до однострочного: 

computed: {
  ...mapGetters('interface', ['active', 'mode', 'views']),
}
  • В-третьих, как только вы начнете иметь несколько строк, просто будет легче отслеживать все объявления(например, сколько полей getters или state вы выставляете из каждого модуля).Таким образом, эти вспомогательные функции на самом деле помогают улучшить ремонтопригодность при правильном использовании. 
computed: {
  ...mapState('interface', ['list', 'packages']),
  ...mapGetters('interface', ['active', 'mode', 'views']),
  ...mapGetters('foo', ['bar', 'baz']),
}

  • Далее, что касается размера пакета, со второго взгляда я считаю, что это может быть основной причиной, по которой люди отказались от голосованиявы.Итак, я попытаюсь объяснить:

    Что вам нужно понять, так это то, что в настоящие производственные веб-приложения в наши дни используются такие инструменты сборки, как webpack, для создания пакетов javascript.И из-за этого написанный вами javascript можно в значительной степени считать source code, что полностью отличается от кода, поставляемого в комплекте.Причина, по которой они так различны, заключается в том, что в пакете могут использоваться методы minify и gzip для достижения значительного улучшения размера файла (обычно на практике уменьшение размера более чем на 70%).

    Другими словами, для веб-приложений в наши дни javascript - это , а не , который предоставляется как есть, но почти всегда обрабатывается webpack или подобным.Таким образом, все подсчеты символов, которые вы выполняли на source code, не будут заметно влиять на окончательный размер набора.И из-за этого некоторые люди могут расценивать вашу обеспокоенность как крайне плохую форму микрооптимизации, а значит, и свои отрицательные отзывы.

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

Итак, для меня эти функции (mapState, mapGetters, mapActions, mapMutations) определенно стоит использовать.

...