на тему подходов к стору - вот и озадачился. В таком случае, было бы также интересно узнать ваше мнение насчет:
1. Выходит, "идеальный флакс" стремится к отказу от локальных состояний компонента от слова вообще?) Как, в таком случае, поступать с небольшими данными, которые узко необходимы только одному компоненту в приложении?
2. Я во Vue недавно, на днях познакомился с популярным в комьюнити срачем: что думаете насчет mapState и mapMutations? Уместны ли прямые мутации из компонентов, на ваш взгляд? Почитал https://github.com/vuejs/vuex/issues/587 , но к окончательному выводу так и не пришел
1 От небольших кусков сложно избавиться, это может быть например пользовательский ввод, странновато будет на каждый новый символ сразу вызывать мутацию Эта отождествленность компонента от состояния должна помочь лучше понимать сам компонент, давать возможность эффективно его тестировать и представлять его в виде черной коробки, в которую что-то вышло и из которой что-то вышло. Размер этой коробки определяете вы сами. Вы ведь не будете тестировать на уровне «ввел символ а, в инпуте появилось а» Четкой грани тут нет наверно, по крайней мере я о ней не знаю, все бизнес данные я храню в хранилище, существенные интерфейсные переменные тоже, логику ввода данных оставляю внутри своего черного ящика 2 Думаю, что иногда это излише, в простых вопросах и аппках вполне можно сделать это «упрощение», понимая это Если это не противоречит чему-то еще, например автогенерации документации на основе всех экшенов или еще чему-то или нарушению цельного стиля большого проекта Правило должно иметь под собой что-то, какую-то ценность. Если есть обоснование - то да. Например вы делаете проект в команде и отдаете часть работы над компонентами людям, которым не нужно думать о том будет ли действие синхронно или асинхронно, тогда - да, это оправдано, это снимает ряд вопросов с некой команды. А так, у меня например есть мутация «установить title страницы», я не писал поверх нее экшен
Обсуждают сегодня