BKonstantine/task_management_system

Ревью ДЗ Лекция 7 - Vuex

Opened this issue · 1 comments

Сама организация хранилища вопросов не вызывает, но есть вызывает вопросы сама внутренняя логика работы.

  1. наличие дополнительных методов на _REQUEST, _SUCCESS, _ERROR. На текущий момент идея понятна: чтобы использовать их для отображения ошибок и прелоадера. Но в дальнейшем желательно от них избавиться и перейти на использование прелоадера, который не основывается на внутренних состояниях, а вызывается либо автоматически для запросов (как интерсептор, что не всегда может быть нужно), либо вручную перед запуском запроса. Состояние загрузки при этом может храниться в сторе, но оно должно быть абстрактным и не зависеть от контекта выполнения.
  2. saveToken(data.token);
    - токен с localStorage хранить можно, но зачем тогда нужени vuex? Вызвать метод аутентификации можно и без этого и хранить булеву переменную об успешном входе тоже нагрузки не несет, т.к. основным фактором для успешного выполнения запросов является наличие токена. И информация о ходе должна основываться именно на нем. Можно использовать стор в качестве промежуточного слоя для получения данных, когда стор будет использован как обертка надо localStorage для сохранения и получения данных токена и признак того, что пользователь совершил вход будет основан на наличии токена. При этом само приложение напрямую с localStorage работать не будет, а предоставить это хранилищу
  3. по проектам, задачам и пользователям хранить данные в стор конечно можно, но тет особой необходисомти, т.к. они больше нигде не используются кроме собственных представлений. Соответственно их можно хранить в собственных представлениях (включая информацию об общем количестве данных), а вот фильтры для получения этих данных как раз хранить в стор. Фильтры можно объединить в один объект, т.к. при любом изменении любого фильтра нужно перезапрашивать данные. И можно в мутациях избавиться от _CLEAR_FILTER_VALUE, т.к. по сути это тоже самое что и SET_FILTER_VALUE
  4. также можно попытаться найти сходство между фильтрами в разных представлениях и скомпоновать их в единый фильтр

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

И еще один небольшой совет по поводу фильтров (вне ревью): попробуйте избавиться от таких конструкций с присвоением значений отдельным переменным при фильтрации

this.useFilter = true;
. Могут быть ситуации, когда перерабатывая код вы забудете присвоить эту переменную или присвоите ее не там где надо, что будет вызывать ошибки. Проще определять наличие фильтрации в компьютеде через проверку состояния сохраненной фильтрации: если есть значения в каких-то полях фильтра, то значит фильтрация применена, нет значений - не применена. Так вы обезопасите себя от ошибок кода и взаимодействие будет идти через одну точку входа, т.е. от основываться именно на наличии рельных данных, а не вспомогательных переменных, которые от не зависят от данных