Comments 18
не хотел вас расстраивать, гляньте pathify
Использую его, доволен.
Я посмотрел, и я не расстроен.
vuex-pathify действительно очень крутая библиотека. Классный синтаксис а-ля Laravel и множество разных функций, уменьшающих бойлерплейт.
Есть несколько особенностей.
- Она весит столько же, сколько весит весь vuex. Неминифицированный, даже больше. Мне лично, наверное, было бы все равно, но кто-то будет недоволен;
- Синтаксис классный, но он свой. Его надо учить, к нему надо привыкать, и человек со стороны, не знающий эту библиотеку его не поймет.
Я даже не пытаюсь конкурировать с другими сторонними библиотеками. Я просто добавляю 2 новых метода, которые минимально отличаются от оригинальных. И, конечно, в моих самых смелых фантазиях, они вообще должны попасть в ядро vuex.
Да, я знаю, что эта давняя тема, такая же, как использование констант для имён мутаций. В целом, считают, принятие того или иного подхода должно отталкиваться от реалий проекта: размер команды, объём кода, требования к скорости разработки.
Если открыть документацию Vuex про действия (экшены), то там написано вот что:
Действия — похожи на мутации с несколькими отличиями:
- Вместо того, чтобы напрямую менять состояние, действия инициируют мутации;
- Действия могут использоваться для асинхронных операций.
Поэтому я не согласен с тем, что "экшен всегда возвращает промис". Экшен вообще не обязательно должен быть асинхронным.
Действия – это просто высокоуровневые обертки над мутациями. Если мутация делает что-то конкретное со state, притом обязательно синхронно, то действия придуманы как раз для того, чтобы быть "контроллерами" над мутациями.
Действия должны выглядеть как API для взаимодействия со store, а не просто как аналог мутаций, только с асинхронными возможностями.
Я просто сталкивался с кодом, в котором много вызовов dispatch сделаны в синхронном стиле. И проблема в том, что были места, где такое использование по недосмотру приводило к ошибкам.
Просто часто для программиста вся разница между вызовом действия и мутации — просто вместо mapActions написать mapMutations. Собственно, ваша библиотека и убирает эту грань, но мне обычно хочется чётко понимать, что тут dispath делает асинхронное обращение к API, а тут commit сразу меняет state. Хочу контролировать всю «асинхронщину» в коде, т.к. ошибки такого рода сходу не видны.
Да, я был не прав.
Я не знал, что там в ядре прописано return new Promise. Я имел в виду, что не все экшены обязательно должны быть асинхронными.
Но хочу кстати сказать, такая вариативность подходов во Vue позволяет гибко подстраивать фреймворк под нужды проектов.
Например, у меня была задача сохранять параметры приложения в url. Классически, это решается через vue-router, проброс url-параметров в props-компонента, смена параметров через $router.push, watch-ере на $route и так по кругу.
В моём случае мне не хотелось переносить хранение части данных вне стора, хотелось сохранить state как единственный источник правды. И не хотелось менять существующий код работы с хранилищем. Поэтому я сделал зеркалирование некоторых параметров state в url при их изменении. Самое интересное, во vuex даже был подходящий метод (watch), позволяющий такое сделать. И это действительно классно, что vue позволяет гибко расширять функционал.
Конкретно во vuex и правда неплохо работают упомянутые naming conventions, например mutations капсом, actions кэмелкейзом — то, что чаще всего встречал.
+1
А давайте напишем фреймворк для фреймворка? )
Конвенции и настроенный линтинг/анализатор решит ненужные проблемы.
А стандартные мапперы (mapState и др.) – это тоже отдельный фреймворк фреймворка? Только уже встроенный внутрь заранее.
Вот vuex-pathify – это действительно фреймворк фреймворка. Без вопросов (хотя я не имею ничего против фреймворков фреймворков и т.д.)
У меня лишь пару дополнительных методов, которые ничего принципиально не меняют.
Я призываю использовать что то стандартное, Вы призываете "делайте как я"
Возможно вы этого даже не понимаете.
В итоге какое то не понятное правило для бабел и куча ошибок в существуюших проектах
Это вы делите всё на "черное" и "белое". Я просто предлагаю альтернативные варианты и доказываю, почему мои варианты удобнее.
Единственное место в статье, где я четко сказал, что "так делать не надо", – это в начале про статью, где автор утверждает, что писать геттеры для всех значений – это ошибка.
Я не считаю, что это ошибка. Но я и не утверждаю, что не писать геттеры, – ошибка.
Я не считаю, что это ошибка.
А давайте призывать писать новый класс на каждый геттер? Не ну а ч0, там и валидация потом (через класс валидации конеш). Мало ли что нерадивые девелоперы в параметры гетера передадут.
ЗЫ. Я сам за валидацию и прочее, но не считаю нужным "выносить" это куда то. Это оправдано для всяких либ, но не как не для проекта.
Горький опыт когда по "сообщению об ошибке" нужно перебрать тыщу файлов.
А mapData, да, наверное можно использовать что-то подобное.
Vuex – решаем старый спор новыми методами