Комментарии 19
А почему плохо, я так и не понял. Я лично делаю геттер и вот почему: стэйт обычно нужен когда несколько компонентов работают с одними данными, и геттер лучше будет в одном месте а не в нескольких компонентах. Создаю его я даже если он только в одном уомпоненте используется, и отчасти не потому что «пусть будет, мало ли какой новый компонент его потребует», а потому что его сделал, добавил в юнит тест стораджа и забыл.
...mapGetter(['films']),
выглядит точно так же красиво как
...mapState(['films']),
Так что я не могу согласится с первыми 2 пунктами, по крайней мере пока не увижу реальный проблемы с ними.
По третеьему пункту соглашусь. Геттеры с параметрами это боль. Особенно тестирование.
Как бы вы рекомендовали решить проблему обращений к апи внутри экшенов? Я сам этим грешил поначалу, но впоследствии стал выносить всю логику обращения к апи в отдельную либу, свою для каждого модуля. В итоге внутри экшена у меня идет вызов импортированного метода, возвращающего промис с которым я дальше уже работаю. В экшенах чисто, а все апи как на ладони в отдельном файле.
С флагами тоже поддерживаю, а ведь именно так раньше я и делал. Управление флагами загрузки оказалось гораздо более гибким и очевидным если оно реализовано внутри компонента, а не стора.
<li v-for="(film,index) in $store.state.films" :key=index>
{{film.title}}
</li>
Или в этом случае кошернее будет обращаться к $store.state.* напрямую?
Но если вы в сторе держите напрямую поле userName, то лучше делать ...mapState(‘userName’). Разработчики, которые будут поддерживать код после вас скажут вам спасибо)
Вы снова не ответили на вопрос чем это лучше.
А если понадобится поменять имя поля? Искать все кейсы с mapstate или один раз в одном геттере изменить.
user: {
roles: ['IS_ADMIN', 'IS_COMPANY', 'IS_USER'],
...
}
В сторе у меня есть глобальный геттер, который определяет, является ли пользователь админом:
isAdmin() {
return this.state.roles.includes(Roles.ROLE_ADMIN);
}
.reduce((result, film) => ({
...result,
[film.id]: film,
}), {})
Вместо простого алгоритма наполнения хэша со сложностью O(n) получается n наполнений хэша общей сложностью O(n!). Создается n промежуточных объектов. В некоторых случаях это может создать большую нагрузку на GC, т.к. общее количество ключей во всех этих объектах тоже будет n!..
Такое будет работать быстро в функциональных языках, благодаря оптимизациям, которые возможны из-за других особенностей языка. В других языках, включая js, этих оптимизаций может не быть (скорее всего).
Подходы ФП могут сделать код читаемым и лаконичным. Хотя в этом примере страдает даже читаемость.
const [film = {}] = state.films.filter(f => f.name === 'Джеймс Бонд');
Понятно, что это только пример, но все-таки правильнее использовать Array.find
const film = state.films.find(f => f.name === 'Джеймс Бонд') || {};
Несколько простых, но полезных советов по работе с геттерами в Vuex