При использовании mapState, вам надо знать о структуре данных в модуле ровно столько же, сколько и при использовании mapGetters. Если я не прав — приведите пример в котором это не так.
Вы немного лукавите приводя примеры кода.
Я имею ввиду что если использовать геттеры для каждого куска состояния, то код увеличивается, прежде всего, в хранилище. И с этим уж никто не поспорит, так как это очевидно и я даже пример приводить не буду.
Но в ваших примерах вы приводите также код из компонента. Давайте рассмотрим несколько вариантов:
Вариант 1:
Допустим я не использую mapState и mapGetters. Тогда объем кода в компоненте для меня не меняется так как я в любом случае создаю вычисляемое свойство и в нем одной строкой возвращаю состояние хоть из стейта, хоть из геттера:
// Без геттера users()
users() {
return this.$store.state.users;
},
// С геттером users()
users() {
return this.$store.getters.users;
},
Тут объем кода одинаков (на самом деле нет — не используя геттер мы сэкономим 2 символа, но это мелочи).
Вариант 2:
Допустим я использую mapState и mapGetters.
// Без геттера users()
...mapState([
'users'
]),
// С геттером users()
...mapGetters([
'users'
]),
Снова не вижу разницы.
Тут вы наверное заметите что я вас обманул, так как не использую и mapState, и mapGetters одновременно. Что ж — вы правы, если использовать их вместе, то код в компоненте увеличится:
// Без геттера users()
...mapState([
'users'
]),
...mapGetters([
'articles',
'comments'
]),
// С геттером users()
...mapGetters([
'users',
'articles',
'comments'
]),
Но должен сказать что эти 2 лишние строчки скорее всего окупятся теми строками, которые вы не напишите в хранилище. И еще по своему опыту могу сказать следующее: так как я не пишу геттеры для каждого свойства в состоянии, то мне очень (очень очень) редко приходится использовать в компоненте mapState и mapGetters одновременно. А значит и в последнем случае — я не получу выгоды от вашего подхода.
Если я неправильно понял и имелось ввиду, то о чем вы говорите то дополню:
Если после изменения структуры хранилища те данные которые были не производными — стали производными, то надо добавить геттер для них и это не будет противоречить тому что написано в статье. Но не стоит добавлять геттеры для всех данных "по умолчанию".
На самом деле все просто. Эта и множество других, похожих как две капли воды, статей про геттеры Vuex пытаются донести одно простое правило:
Приложение перегружается тем, что это увеличивает объем кода. И на связность это никак не влияет, потому что такие геттеры попросту отдают состояние. В общем геттер вида:
getUser(state) {
return state.user;
}
Это просто лишний кусок кода и лишний вызов функции при работе приложения. Не то чтобы он сильно нагружает приложение, но и ценности никакой не имеет.
То не надо пихать его в хранилище в таком виде в каком он пришел. Надо сразу же в обработчике результата запроса или в экшене или, на худой конец, в мутации привести объект к такому формату с которым ваше приложение привыкло работать:
let user = {
"name": rawUser.login,
"sex": rawUser.male ? "male" : "female",
"image": "https://site.ru" + rawUser.avatar
};
И только после этого сохранять его в состоянии.
А откладывать преобразование формата на самый последний момент (в геттер) — это по прежнему не правильно. Геттеры нужны только для того чтобы вычислять производное состояние на основе состояния хранилища. Т. е. это практически то же самое, что computed в компонентах.
Мне повезло с Дедом Морозом, он быстро отправил подарок и поделился трек-номером, чтобы я его не пропустил. )
Но главное что он удачно выбрал подарок, так как я буквально на этой неделе решил запилить какое-нибудь приложение для управления гаджетами по Bluetooth и искал себе подопытное устройство. )
Но пусть мой Дед не переживает — я обещаю не переусердствовать с экспериментами и даже буду использовать подарок по прямому назначению так как портативной колонки у меня до этого не было, а вещь действительно нужная.
А еще в комплекте идут прикольные наклейки и душевное письмо. )))
И если уж быть совсем точным, то padding-top считается не от ширины родителя, а от ширины доступного пространства. Т. е. если у родительского блока стоит box-sizing: border-box; и есть padding или border, то их размеры вычитаются из той ширины от которой считается padding-top и т. п.
Спасибо, за статью. Местами я даже понимал что иногда чувствую то же самое что и вы, хоть я и работаю программистом уже очень давно. Старайтесь довести свой проект до конца, потому что я считаю это самой трудной задачей. Особенно трудно заставить себя что-то доделать, когда осталось совсем немного. Если нужна будет помощь — обращайтесь. С питоном я знаком мало, но с фронтендом помогу по возможности.
Ну во первых изменение состояние Vuex автоматически вызывает изменения в DOM, а в LocalStorage отследить состояние можно только отследив событие «storage», причем это событие не сработает если оно вызвано кодом исполняемым в той же вкладке.
Во вторых в LocalStorage можно хранить только строки, а чтобы поместить туда хотябы простейший объект — его надо сериализовать.
В третьих localStorage сохраняет свои данные после закрытия вкладки и обновляет свои данные сразу во всех вкладках, в которых открыт сайт, а это далеко не всегда нужно.
Ну и еще много причин. Если в кратце — то это разные механизмы, предназначенные для разных задач и заменить одно другим нельзя.
Очень крутой стеб. ))) Не сразу понял в чем подвох.
Жаль только качество перевода оставляет желать лучшего. Исправьте хотя бы явные орфографические ошибки.
Было бы очень полезно если бы вы это описали. Кстати эту строку можно заменить на эту:
В JS нет метода findIndexOf().
Насчет увеличения связности...
При использовании mapState, вам надо знать о структуре данных в модуле ровно столько же, сколько и при использовании mapGetters. Если я не прав — приведите пример в котором это не так.
Насчет увеличения объема кода...
Вы немного лукавите приводя примеры кода.
Я имею ввиду что если использовать геттеры для каждого куска состояния, то код увеличивается, прежде всего, в хранилище. И с этим уж никто не поспорит, так как это очевидно и я даже пример приводить не буду.
Но в ваших примерах вы приводите также код из компонента. Давайте рассмотрим несколько вариантов:
Вариант 1:
Допустим я не использую mapState и mapGetters. Тогда объем кода в компоненте для меня не меняется так как я в любом случае создаю вычисляемое свойство и в нем одной строкой возвращаю состояние хоть из стейта, хоть из геттера:
Тут объем кода одинаков (на самом деле нет — не используя геттер мы сэкономим 2 символа, но это мелочи).
Вариант 2:
Допустим я использую mapState и mapGetters.
Снова не вижу разницы.
Тут вы наверное заметите что я вас обманул, так как не использую и mapState, и mapGetters одновременно. Что ж — вы правы, если использовать их вместе, то код в компоненте увеличится:
Но должен сказать что эти 2 лишние строчки скорее всего окупятся теми строками, которые вы не напишите в хранилище. И еще по своему опыту могу сказать следующее: так как я не пишу геттеры для каждого свойства в состоянии, то мне очень (очень очень) редко приходится использовать в компоненте mapState и mapGetters одновременно. А значит и в последнем случае — я не получу выгоды от вашего подхода.
Если я неправильно понял и имелось ввиду, то о чем вы говорите то дополню:
Если после изменения структуры хранилища те данные которые были не производными — стали производными, то надо добавить геттер для них и это не будет противоречить тому что написано в статье. Но не стоит добавлять геттеры для всех данных "по умолчанию".
На самом деле все просто. Эта и множество других, похожих как две капли воды, статей про геттеры Vuex пытаются донести одно простое правило:
Не надо делать такие геттеры:
Приложение перегружается тем, что это увеличивает объем кода. И на связность это никак не влияет, потому что такие геттеры попросту отдают состояние. В общем геттер вида:
Это просто лишний кусок кода и лишний вызов функции при работе приложения. Не то чтобы он сильно нагружает приложение, но и ценности никакой не имеет.
Вы не правы.
Если формат данных меняется, то надо приводить данные к нужному формату еще на входе.
Например API возвращал объект в одном формате:
А потом стал возвращать в другом:
То не надо пихать его в хранилище в таком виде в каком он пришел. Надо сразу же в обработчике результата запроса или в экшене или, на худой конец, в мутации привести объект к такому формату с которым ваше приложение привыкло работать:
И только после этого сохранять его в состоянии.
А откладывать преобразование формата на самый последний момент (в геттер) — это по прежнему не правильно. Геттеры нужны только для того чтобы вычислять производное состояние на основе состояния хранилища. Т. е. это практически то же самое, что computed в компонентах.
Но главное что он удачно выбрал подарок, так как я буквально на этой неделе решил запилить какое-нибудь приложение для управления гаджетами по Bluetooth и искал себе подопытное устройство. )
Но пусть мой Дед не переживает — я обещаю не переусердствовать с экспериментами и даже буду использовать подарок по прямому назначению так как портативной колонки у меня до этого не было, а вещь действительно нужная.
А еще в комплекте идут прикольные наклейки и душевное письмо. )))
Дед Мороз, спасибо тебе ОГРОМНОЕ!!!
Чуть чуть недоперевели.
content-boxэто в моем понимании и есть «доступное пространство», просто не знал как его правильно обозвать.box-sizing: border-box;и есть padding или border, то их размеры вычитаются из той ширины от которой считается padding-top и т. п.Не высоты, а ширины.
Не совсем так. За отступ берется не сумма а максимальное значение из Margin 1, Margin 2 и Margin 3.
Наоборот. Не отличается от initial, а равно initial. Или visible.
Спасибо, за статью. Местами я даже понимал что иногда чувствую то же самое что и вы, хоть я и работаю программистом уже очень давно. Старайтесь довести свой проект до конца, потому что я считаю это самой трудной задачей. Особенно трудно заставить себя что-то доделать, когда осталось совсем немного. Если нужна будет помощь — обращайтесь. С питоном я знаком мало, но с фронтендом помогу по возможности.
Во вторых в LocalStorage можно хранить только строки, а чтобы поместить туда хотябы простейший объект — его надо сериализовать.
В третьих localStorage сохраняет свои данные после закрытия вкладки и обновляет свои данные сразу во всех вкладках, в которых открыт сайт, а это далеко не всегда нужно.
Ну и еще много причин. Если в кратце — то это разные механизмы, предназначенные для разных задач и заменить одно другим нельзя.
Тут должно быть не
dispatch, acommit— иначе получается какая-то рекурсия.И просто прочтите остальной текст — сами все увидите.
Насчет снятия с публикации — решайте сами. Я бы постарался довести перевод до нормального состояния.
Жаль только качество перевода оставляет желать лучшего. Исправьте хотя бы явные орфографические ошибки.