Open kompolom opened 8 years ago
@kompolom https://github.com/bem-contrib/bem-redux
@Yeti-or Спасибо!
Осталось несколько моментов, которые никак не укладываются в моей голове. Буду сильно благодарен, если поможете разобраться:
При изменении store рендерить блок полностью - кажется слишком накладно.
@Guria Это ж только PR... Может есть другие решения, например, для тех, кто не использует bem-xjst?
Если мы идем по пути "Store as singleton" - У нас получится гигантский store которым нужно как-то управлять.
Это ведь так и задумано в redux.
При изменении store рендерить блок полностью - кажется слишком накладно.
В принципе реагировать на изменение стора можно произвольной логикой, не обязательно перерисовывать все целиком.
@tadatuta
Это ведь так и задумано в redux.
Да, задумано. Нет ли в этом противоречия БЭМ?
Нет :)
Это ведь так и задумано в redux.
Не понимаю, почему обязательно ограничиваться одним. Скорее, одним на приложение, или одним на сцену.
Пока никак не пойму как лучше задать начальное состояние приложения в браузере. Может что то посоветуете?
И еще, actions получается, должны быть уникальными для каждого блока? Например, если я просто создам action { type : 'CHANGE_TAB', index : 1 }
то поменяются все табы в приложении?
@kompolom initialState вот https://github.com/reactjs/redux/blob/master/docs/recipes/ServerRendering.md#clientjs в оригиналином redux уникальные константы только внутри одного редьюсера на каждый экшен
У кого получилось собрать "рабочий кейс" использования Redux в БЭМ проектах (на i-bem)?
Есть рабочий кейс с flux, кажется с redux не должно быть проблем тоже.
@awinogradov ты про этот говоришь https://github.com/bem-contrib/bem-flux?
Меня интересует (при использовании Redux) организация Reducers. Сейчас до дыр перечитываю описания их организации, но пока не совсем понимаю как это организовать в SPA (и при этом чтобы не тормозило)
Я про продакшен. Используется свой самописный.
Sent from my iPhone
On 26 Jul 2016, at 22:00, Sergey Belozyorcev notifications@github.com wrote:
@awinogradov ты про этот говоришь https://github.com/bem-contrib/bem-flux?
Меня интересует (при использовании Redux) организация Reducers. Сейчас до дыр перечитываю описания их организации, но пока не совсем понимаю как это организовать в SPA (и при этом чтобы не тормозило)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@belozyorcev кажется нет смысла использовать redux c i-bem. Redux будет хорош с virtualDOM, а i-bem.js с ним (virtual DOM) не дружит.
А можешь пояснить как паттерн работы с данными связан с виртуальным деревом и почему именно хорошо не будет?
Sent from my iPhone
On 27 Jul 2016, at 08:06, Evgeniy Baranov notifications@github.com wrote:
@belozyorcev кажется нет смысла использовать redux c i-bem. Redux будет хорош с virtualDOM, а i-bem.js с ним (virtual DOM) не дружит.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@awinogradov так что вы получаете весь обновленный state как есть.Чтобы привести DOM в соответствие с новым state вам придется либо заново отрендерить весь state или его кусок, либо каким-то способом делать diff и рендерить изменения. Грубо говоря можно использовать и без virtual DOM но смысл?
Redux или Flux просто реализуют хранилища данных и предлагают определенный паттерн работы с ними. То есть мы реагируем на события изменений store. Блоки подписаны на события и что-то с собой делают. Кажется событийная модель вполне себе ложится на i-bem?
@awinogradov проблема возникает в ситуации если на странице 100 блоков. Происходит action ADD_TRACK
Наш контейнер слушает изменения Store. Теперь ему нужно как-то определить, что был добавлен новый элемент, или перерисовать весь контейнер заново (что более затратно). Здесь мой мозг входит в ступор и не даёт старт использованию Redux.
С react проще, т.к. он определяет что нужно дорисовать/перерисовать.
Делай маленькие блоки, а в данных store держи bemjson. Да это менее эффективно чем при работе с виртуальным деревом, но тебе шашечки или ехать?)))
А ещё я не знаю, можно ли сделать так store
{
route: reducer(),
app: {
page1: {
users: reducer(),
params: reducer()
},
page2: {
users: reducer(),
}
page3: {
widgets: reducer(),
}
}
}
В общем нарыл насобирал несколько пакетов из которых можно вынести пользу (при отсутствии VirtualDOM).
ну и также куча других библиотек для diff https://github.com/search?utf8=✓&q=js+diff
@awinogradov а можешь привести пример как хранить bemjson? Я не совсем понимаю как редьюсеры выстраивать при таком подходе.
@belozyorcev не вижу разницы. Каждое поле store ты можешь выделить под блок. Подписать каждый блок на свой участок и матчится на bemjsonApi каждого блока.
Привет всем! Начал посматривать в сторону redux. Сама идея довольна интересна, хотя окончательно в голове не уложилась. Хотелось бы узнать мнение сообщества о паттерне, укладывается ли он в методологию БЭМ.