@kompolom https://github.com/bem-contrib/bem-redux

@Yeti-or Спасибо!

Осталось несколько моментов, которые никак не укладываются в моей голове. Буду сильно благодарен, если поможете разобраться:

• Если мы пошли по пути "Block as state container" - как осуществляется взаимодействие между блоками. Не получится ли что мы снова пришли к MVC?
• Если мы идем по пути "Store as singleton" - У нас получится гигантский store которым нужно как-то управлять.
• При изменении store рендерить блок полностью - кажется слишком накладно.

При изменении store рендерить блок полностью - кажется слишком накладно.

#961

@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).

• https://www.npmjs.com/package/redux-watcher (слежение за изменением определённых узлов store)
• http://benjamine.github.io/jsondiffpatch/demo/index.html (ещё один пакет для отслеживания изменений)

ну и также куча других библиотек для diff https://github.com/search?utf8=✓&q=js+diff

@awinogradov а можешь привести пример как хранить bemjson? Я не совсем понимаю как редьюсеры выстраивать при таком подходе.

@belozyorcev не вижу разницы. Каждое поле store ты можешь выделить под блок. Подписать каждый блок на свой участок и матчится на bemjsonApi каждого блока.