Противоречит ли соглашению использовать `Vue.nextTick` в мутации Vuex? Может ли это что-то сломать?

#javascript #vue.js #vuex

#javascript #vue.js #vuex

Вопрос:

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

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

Комментарии:

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

2. Спасибо за комментарий. Я уже использовал для этого действия, но хотел превратить их в мутации. Может быть, я мог бы просто разделить код и переместить только некоторые его части в мутации и оставить это как действие, например. Мне нужно будет проверить, возможно ли это.

3. Но зачем переходить к мутации, если в качестве действия она работает нормально? Если это причина ясности, конечно, вы могли бы разделить его на несколько действий / мутаций. Но асинхронная часть должна оставаться в действиях! 🙂

4. @Kapcash, ясность — одна из причин, но я также подумал о будущей возможности отменить или повторить некоторые изменения на основе мутаций. Хотя спасибо. 🙂

Ответ №1:

Использование nextTick в мутации эффективно перемещает код за пределы мутации, поэтому вы будете получать ошибки в строгом режиме, и Devtools не сможет отслеживать изменения.

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

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

Комментарии:

1. Спасибо за ответ. Я думал об использовании getter, но, похоже, его вызывали несколько раз, даже когда в этом не было необходимости. Вот почему я решил ввести ручной вызов для сортировки и просто сохранить отсортированный список в state . Может быть, есть какой-то способ избежать ненужных вызовов getter? Или какое-то промежуточное решение, например, наличие переменной sortingRequired ? Я думал об использовании некоторых watch , но, насколько я знаю, в самом Vuex или при определении хранилища нет ничего подобного, и мне пришлось бы делать это в каком-то компоненте или «main.js «.

2. @kcpr getters работает так же, как computed свойства. Кэшированное значение будет признано недействительным, как только изменится зависимость, но вычисление нового значения является ленивым и произойдет только в том случае, если что-то попытается использовать это значение. Одна из потенциальных проблем заключается в том, что она может быть признана недействительной в тех случаях, когда на самом деле ничего важного не изменилось, возможно, это проблема, с которой вы столкнулись. Обман, связанный sortingRequired со свойством и наблюдателем, может быть законным подходом в крайних случаях. Composition API делает это немного проще.