Vuex — чрезмерное использование геттеров в приложении. Разбор ошибки

Думаю речь шла не про изменение формата данных из API, а про периодическую необходимость менять структуру стейта какого-то модуля (что-то добавилось, что-то решили больше внутрь убрать).

Vuex — чрезмерное использование геттеров в приложении. Разбор ошибки

Не согласен. А есть ли вообще увеличение объема кода, сравним:
1)

// модуль
const getters = {
...
 getUser: state => state.user
...
}

// компонент
...mapGetters({
   user: 'module/getUser',
   // другие геттеры
})

2)

{
   ...mapState({
     user: state => state.module.user,
   }),
   ...mapGetters({
   // другие геттеры
     ...
   })
}

Как видно, увеличение объема кода в случае 1 будет только в случае, когда другие геттеры не используются и надо писать mapGetters. Во всех остальных ситуациях же кода больше будет как раз таки в случае 2 из-за необходимости использовать и mapState, и mapGetters. Ну в целом по объему кода разницы большой нет, и это не критичный момент во всей этой ситуации на мой взгляд.

И на связность это никак не влияет, потому что такие геттеры попросту отдают состояние

Геттеры попросту отдают состояния и при использовании их извне мне не надо думать про структура стейта, а вот как раз через mapState мне каждый раз приходится задавать путь в стейте, т.е. компонент начинает что-то знать о структуре данных в модуле -> это и есть увеличение связности.

Понятно, что ничего критичного в этой увеличенной связности нет, но все таки не могу согласиться с односторонним называнием «неправильным» подхода с использованием только геттеров. Лично я предпочитаю общение со стейтом только через геттеры, потому что: a) не надо думать о структуре стейта в компоненте б) не надо использовать и mapState и mapGetters в) при изменении структуры не надо думать, есть ли какие-то места в приложении, обращающиеся к стейту напрямую, я всегда знаю что доступ к нему будет осуществляться только через заданный мной интерфейс — геттеры. Пробовал оба подхода и второй оставляет ощущение большей «чёткости».

Vuex — чрезмерное использование геттеров в приложении. Разбор ошибки

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

А вообще смахивает на перевод статьи с медиума годовой давности.

Дискредитация специалистов или современные собеседования

Моднейшие технологии по работе с массивами под названием map и reduce. Лол. Вы живите нездоровыми иллюзиями, называя модными технологиями стандартные средства es. Это не модная технология, это уже давно стало стандартом языка, а вы всё это время с жиквери ковырялись и даже не заметили. Ну а в яндексе-то конечно дураки за пару дошираков массивы мапами и редьюсами гоняют.

Дискредитация специалистов или современные собеседования

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

Дискредитация специалистов или современные собеседования

Ваше понимание устарело лет на 6.

Дискредитация специалистов или современные собеседования

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

Дискредитация специалистов или современные собеседования

Интересный у вас фронт-енд без массивов и map и reduce… jquery в 2018м?

Задай вопрос создателю Vue.js

В смысле еще один? Vue уже достаточно давно на арене и для многих разработчиков предпочтительнее других