Alex

Вы в мутации изменяете рутовый объект. То есть вы написали что-то в таком духе

const state = {data: {user: ''}}
state.user = '...' // <-- Изменяете не то поле

Вам нужно изменять подъобект data

const state = {data: {user: ''}}
state.data.user = '...' // <--

Выносите всё что хотите в отдельные файлы, а потом просто импортируете ...

Вам нужен плагин. По типу vuex-shared-mutations. Он использует BroadcastChannel, что в теории может заработать в многооконном electron. Ну, а если не взлетит – вы можете написать собственную стратегию используя ipc и интегрировать её в этот плагин

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

Для таких случаев, существует debounce

Простейший способ рекунривно скопировать объект:

const copy = JSON.parse( JSON.stringify( source ) )

Ну, а сохранять — вызвать action и передать в него вашу копию.

1. Да
   
2. Тут всё просто: Функцция или данные нужны только в одном компоненте или в нескольких? В одном — всё в компонент. Иначе в хранилище. Сами мутации должны быть как можно легче. Они блокируют интерфейс.
   
3. Чем меньше тем лучше. Любую несвязанную логику лучше выносить в отдельный компонент. Это опять таки скажется на производительности в лучшую сторону
   

Ссылки:

• https://ru.vuejs.org/v2/style-guide/index.html
  
• https://habr.com/ru/post/483042/
  
• https://arutyunov.me/blog/vue/26-sovetov-dlya-vue-...
  

Создайте ещё один геттер во Vuex и используйте его в компонентах:

export const getters = {
  filters: st => st.filters,
  ageRatings: (state, getters) => getters.filters.age_ratings.sort((a,b) => parseInt(a) - parseInt(b))
}

Собственно почему vuex не подходит для огромного числа коммитов?

Потому что при каждом комите Vue проходится по всем зависимостям, пересчитывает их, пересчитывает состояния всех компонентов, изменяет DOM где это нужно. А это всё блокирующие операции.

Лучше используйте EventBus : транслируйте разыне события, не просто "drag" но и "dragstart" и "dragend". Передавайте с событиями нужные координаты. И создавайте компоненты-подписчики на нужные события.

Отдельно можете добавить тротлинг. Не большой, буквально до 100 миллисекунд. Уже это существенно уменьшит количество комитов, а интерфейс останется таким же "мгновенным"

запросы к API надо делать внутри actions Vuex (якобы это best practices). Однако, я совершенно не понимаю, всегда ли это необходимо

state нужен в тех случаях, когда доступ к списку пользователей вам нужен не в одном компоненте, а как минимум в двух. В таких случаях без него никак.

Если вы уверены, что список пользователей вам нужен только в одном компоненте — тогда все данные нужно хранить именно в нем.

Важно понимать разницу:

• Данные в Vuex "существуют" всегда и всегда занимают часть памяти на клиенте.
  
• Данные в компоненте "существуют" только когда существует компонент. И будут удалены если удалится компонент.
  

Если ваше приложение завязано на списке пользователей, и несколько компонентов используют эти данные, то без Vuex вам будет сложно.

В то же время, если список пользователей вам нужен только для какого-то виджета, который отображается не всегда — тогда хранить данные в Vuex не стоит.

См. также

Подскажите, что делать дальше, после того как запрос ушел на сервер и мы получили ответ, что пользователь добавлен?

Это вопрос уже совершенно другого направления.

Создать и вызвать мутацию addUser для добавления нового пользователя в state?

Да. Actions для того и существует, чтобы вы могли выполнить какие-то асинхронные запросы, доп проверки, валидацию данных, определить нужно ли что-то сохранить в state и если нужно — что именно. Здесь вы можете добавить пользователя, проверить добавился ли он, выполнить дополнительный запрос на извлечение информации о нем. И тп.
А мутация — непосредственно алгоритм изменения состояния.

в чем тогда смысл нашего state?

Локальная, быстрая, реактивная копия данных с сервера на клиенте.

при любом действии все равно необходимо загружать данные с сервера

Это уже вопрос к серверу. И к его API. Есть много разных технологий синхронизации данных между сервером и клиентом.

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

Все данные в state должны быть логически разделены на модули. Все комиты тоже должны быть логически разделены внутри каждого модуля. Лично я предпочитаю вообще не создавать корневого хранилища — всё в подмодулях.

Что касается валидации, то Aetae всё верно написал.

Лично я использую следующий подход. Он не лучший, и не всегда подходящий.
— Все компоненты вызывают только action
— Комиты вызываются только внутрии action после всех проверок и валидаций.
— Все комиты расчитаны на получение заведомо корректных данных.

Таким образом:
мутация — низкоуровневый инструмент для управления хранилищем.
action — высокоуровневый менеджер по управлению хранилищем, который проверяет все данные, выполняет любые дополнительные манипуляции, преобразования, разбивает большие данные на части если это нужно и так далее, и только потом уже готовые данные передаёт в мутацию.
компонент — пользователь хранилища. Которые не вызывает мутации напрямую, а вызывает только action. И в исключительных случаях может получить прямой доступ к хранилищу в обход любых проверок и изменений вызвав напрямую мутацию.

По итогу написал что-то такого:

getters: {
  getPostsByCategory(state) {
    const map = new Map();
    state.posts; // Необходимо чтобы геттер пересчитывался при изменении state.posts

    return (catId) => {
      if (map.has(catId)) {
        return map.get(catId);
      }

      let posts = state.posts.filter(p => p.catId === catId);
      map.set(catId, posts);


      return posts;
    };
  }
}

Как это работает:
Геттер возвращает не результат, но функцию. Эта функция фильтрует посты, и через замыкание кэширует результат. Если в любом другом компоненте потребуется список постов этой же категории — эни будут возвращены из кэша.

При изменении state.posts — этот внутренний кэш очищается и список постов будет сформирован заново