Комментарии 23
Ну и какой смысл сначала делать statefull компоненты, а потом разными трюками превращать их в stateless?
Для связки с redux надо изначально разрабатывать компоненты, которые redux поддерживают. Такой компонент либо должен принимать допустимые действия (action) для изменения своего состояния как параметры, либо он должен иметь возможность объявить свои редьюсеры.
C vue немного другая ситуация, в нем нет как такагого одностороннего биндинга, как в polymer. Но подобную функциональность можно достигнуть через модификатор sync
Вы сами-то читали документацию по приведенной вами ссылке? sync — это как раз сахар для имитации двустороннего биндинга. И в вашем примере он не нужен совсем.
P.S. может мы по разному понимаем термин «односторонний биндинг»?
В некоторых случаях нам может понадобиться “двухсторонняя привязка” для входных данных — фактически, в Vue 1.x это было представлено модификатором .sync.
… мы удалили модификатор .sync, когда была выпущена версия 2.0…
В версии 2.3.0+ мы снова ввели модификатор .sync для входных данных, но на этот раз это просто синтаксический сахар, который автоматически преобразуется в дополнительный обработчик v-on
Читаем документацию по вашей же ссылке:
В версии 2.3.0+ мы снова ввели модификатор .sync для входных данных, но на этот раз это просто синтаксический сахар, который автоматически преобразуется в дополнительный обработчик v-on:
Следующее
<comp :foo.sync="bar"></comp>
будет преобразовано в:
<comp :foo="bar" @update:foo="val => bar = val"></comp>
Ну и зачем вам в вашем redux-way обработчик @update:foo="val => bar = val"
, который напрямую меняет стор? Куда правильнее будет написать этот @update:foo
самому, засунув туда dispatch
. Заодно можно избавиться от костылей в виде перехвата событий через e.stopPropagation()
.
По поводу костылей, согласен, похоже очень на них, но мне не удалось никак заставить работать нужным образом без них. Буду благодарен любым наводкам на другие подходы.
Вы написали sync — а sync генерирует update, притом не тот что вам нужен. Зачем?
Чем вас не устраивал вот такой вариант:
<input :value="propFromReduxStore" @update:value="changeText"></input>
<input :value.sync="propFromReduxStore" @change="changeText"></input>
Хорошо, а чем ваш вариант лучше вот такого:
<input :value="propFromReduxStore" @change="changeText"></input>
Неужели вы думаете, что компонент будет как-то по-особому вести себя просто из-за того что у него появился обработчик события?
И такой вариант не подойдет, по той причине, что все введенные данный сразу попытаются записаться напрямую в propFromReduxStore, а этого делать нельзя.
Это вы из головы придумали или об этом можно прочитать где-то в документации?
По вашей ссылке я не вижу ничего что подтверждало бы ваши слова.
Вот вам практический пример: https://jsfiddle.net/6wpesep0/2/
Из которого следует, что sync применительно к input.value вообще ничего не делает! Это опровергает ваши слова о том, что "прямого одностороннего биндинга нет" — он есть, и работает по умолчанию, без всяких модификаторов.
И опять-таки, никакой .sync вам не потребовался. И даже e.stopPropagation()
не потребовалось… Тогда о чем вообще ваш пост?
PS все три варианта: https://jsfiddle.net/4zufmzvf/1/
будет написать этот update:foo самому
Согласен полностью, но речь идет об уже написанных не мной компонентах, со своим поведением update, и когда на уровне компонента мы узнаем об нем, то все уже свершилось, а нам надо проникнуть на самое начало этого события. А native позволяет мне перехватить событие в его самом начале, благодаря чему я могу им управлять так как мне надо, а не как реализовано внутри компонента.
Специфика использования Redux в Polymer и Vue