Идея написания статьи появилась в этой ветке, может кому-то будет интересно и её почитать. Сразу скажу, писатель (в том числе кода) из меня так себе, но я буду стараться.
Писать будем как обычно тудулист, надоел конечно до чёртиков, но что-то лучшее для демонстрации придумать сложно. Сразу ссылка на работающее приложение: жмяк (код).
Данные приложения
И сразу в бой, начнём с хранилища. Единственный тип необходимый для этого приложения — Todo:
import { EventEmitter } from 'cellx';
import { observable } from 'cellx-decorators';
export default class Todo extends EventEmitter {
@observable text = void 0;
@observable done = void 0;
constructor(text, done = false) {
super();
this.text = text;
this.done = done;
}
}Тут всё предельно просто, парочка наблюдаемых полей, одно содержит текст задачи, другое статус её выполнения.
Наследование от cellx.EventEmitter необходимо на случай если в дальнейшем понадобится подписаться на изменения какого-то поля:
todo.on('change:text', () => {/* ... */});В данном приложении такого нет и наследование можно убрать, я просто зачем-то всегда пишу его заранее.
Теперь напишем корневое хранилище:
import { EventEmitter, cellx } from 'cellx';
import { observable, computed } from 'cellx-decorators';
import Todo from './types/Todo';
class Store extends EventEmitter {
@observable todos = cellx.list([
new Todo('Primum', true),
new Todo('Secundo'),
new Todo('Tertium')
]);
@computed doneTodos = function() {
return this.todos.filter(todo => todo.done);
};
}
export default new Store();Здесь уже поинтереснее. Используется cellx.list (алиас для new cellx.ObservableList) — наблюдаемый список, наследует от cellx.EventEmitter и при любом своём изменении генерирует событие change. Наблюдаемое поле получая в качестве значения что-то наследующее от cellx.EventEmitter подписывается на его change и тоже изменяется при этом событии. Всё это значит, что не обязательно использовать встроенные коллекции, можно сделать свои унаследовав их от cellx.EventEmitter. Из коробки есть cellx.list и cellx.map. Отдельным модулем есть индексируемые версии обоих коллекций: cellx-indexed-collections.
Ещё один новенький — декоратор computed, вычисляемые поля — это самая суть cellx-a — вы просто пишите формулу вычисляемого поля, вам не нужно самому подписываться на done каждого todo при его добавлении и отписываться от него же при удалении, всё это делает cellx пока вы не видите, вам остаётся расслабиться и получать удовольствие описывая самую суть. При этом описание происходит, можно сказать, в декларативном виде — уже не нужно думать о событиях и о том как изменения будут распространяться по системе, всё пишется так, как будто отработает лишь раз. Кроме того cellx очень умный и автоматически делает некоторые хитрые оптимизации: динамическая актуализация зависимостей и схлопывание и отбрасывание событий не допустят избыточных расчётов и обновлений интерфейса. Если делать всё это вручную, код получается довольно объёмным, но, что намного хуже — глючным. Отладкой же cellx-а заниматься приходиться раз в сто лет, он просто работает.
Представление приложения
Переходим к слою отображения. Сначала компонент задачи:
import { observer } from 'cellx-react';
import React from 'react';
import toggleTodo from '../../actions/toggleTodo';
import removeTodo from '../../actions/removeTodo';
@observer
export default class TodoView extends React.Component {
render() {
let todo = this.props.todo;
return (<li>
<input type="checkbox" checked={ todo.done } onChange={ this.onCbDoneChange.bind(this) } />
<span>{ todo.text }</span>
<button onClick={ this.onBtnRemoveClick.bind(this) }>remove</button>
</li>);
}
onCbDoneChange() {
toggleTodo(this.props.todo);
}
onBtnRemoveClick() {
removeTodo(this.props.todo);
}
}Здесь из новенького — декоратор observer из модуля cellx-react. Грубо говоря, он просто делает метод render вычисляемой ячейкой и вызывает React.Component#forceUpdate при её изменении.
Остаётся корневой компонент приложения:
import { computed } from 'cellx-decorators';
import { observer } from 'cellx-react';
import React from 'react';
import store from '../../store';
import addTodo from '../../actions/addTodo';
import TodoView from '../TodoView';
@observer
export default class TodoApp extends React.Component {
@computed nextNumber = function() {
return store.todos.length + 1;
};
@computed leftCount = function() {
return store.todos.length - store.doneTodos.length;
};
render() {
return (<div>
<form onSubmit={ this.onNewTodoFormSubmit.bind(this) }>
<input ref={ input => this.newTodoInput = input } />
<button type="submit">Add #{ this.nextNumber }</button>
</form>
<div>
All: { store.todos.length },
Done: { store.doneTodos.length },
Left: { this.leftCount }
</div>
<ul>{
store.todos.map(todo => <TodoView key={ todo.text } todo={ todo } />)
}</ul>
</div>);
}
onNewTodoFormSubmit(evt) {
evt.preventDefault();
let newTodoInput = this.newTodoInput;
addTodo(newTodoInput.value);
newTodoInput.value = '';
newTodoInput.focus();
}
}Здесь ещё парочка вычисляемых полей, отличаются от Store#doneTodos они лишь тем, что поля из которых они вычисляются лежат не на текущем экземпляре (this), а где-то в другом месте, cellx никак не ограничивает в этом плане, эти поля можно спокойно переместить в Store и всё так же будет работать. Определять, где должно лежать поле лучше по его сути — если поле специфично для какого-то определённого компонента, то пусть в нём и вычисляется, светиться в общем хранилище ему нет смысла. В данном случае я бы #leftCount перенёс в хранилище, оно вполне может пригодиться где-то ещё, а #nextNumber вполне неплохо смотриться и здесь.
Бизнес-логика приложения
В экшенах cellx никак не используется, поэтому я максимально их упростил, получился даже не Flux, а какой-то MVC в терминах Flux-а. Надеюсь вы мне простите это упрощение.
Результат
В данном случае приложение совсем простое и написать его так же просто можно и без cellx-а (никаких подписок на каждый done здесь не потребуется), при дальнейшем же усложнении связей в приложении сложность их описания на cellx-e растёт линейно, без него — обычно нет и в какой-то момент приходим к мешанине событий в которой без поллитра не разобраться. Для решения проблемы, кроме реактивного программирования, есть и другие подходы со своими плюсами и минусами, но их сравнение — уже другая история (если кратко, как минимум они проигрывают из-за большого количества лишних вычислений и, как результат, более низкой производительности).
В общем-то по коду это всё, ещё раз ссылка на результат: жмяк (код).
Сравнение с другими библиотеками
MobX
Чаще всего спрашивают отличия от MobX. Это наиболее близкий аналог и отличий немного:
- cellx примерно в 10 раз быстрее.
- В статье про атомы я подсмотрел методы/опции put и pull, позволяющие ячейкам уметь чуть больше: синхронизация значения с синхронным хранилищем, синхронизация значения с асинхронным хранилищем, про pull. У MobX я ничего похожего не нашёл.
- Разная система очистки памяти, у cellx это пассивный режим, в MobX вообще нельзя отписаться от ячейки после подписки, что для меня какая-то странность, когда необходима отписка необходимо использовать autorun, который можно "убить" возвращаемым
disposer-ом. Из минусовautorun-а — инициализирующий запуск колбека часто вообще не в тему. - MobX лучше интегрирован с React-ом, в отличии от cellx-а он так же как-то вклинивается в слой бизнес-логики приложения. Я так и не понял зачем он там, но видимо зачем-то нужен.
- У MobX явно лучше с документацией.
Kefir.js, Bacon.js
Тут отличия более существенны. Отставание в скорости ещё больше, но важнее не это. Эти библиотеки предлагают создавать вычисляемые ячейки несколько иначе, в, наверное, более функциональном виде. То, что на cellx-e будет выглядеть так:
var val2 = cellx(() => val() + 1);На этих библиотеках превратиться в что-то вроде (псевдокод, как там точно я не помню, да и не суть):
var val2 = val.lift(add(1));Плюс в более красивом, человекочитаемом коде, минус в заметно большем пороге входа, так как теперь нужно запомнить 100500 методов на все случаи жизни (можно конечно обходиться и каким-то минимальным набором).
В тоже время в cellx-е есть возможность добавить ячейкам свои методы и ничто не мешает довести его до уровня этих библиотек, можно сказать, что он более низкоуровневый.
Подвал
Вопросы по библиотеке и идеи по её дальнейшему развитию принимаются на гитхабе.
Благодарю за внимание.
ЗЫ: Кстати, мы ищем разработчика в команду — вакансия.
Комментарии (81)
RubaXa
18.10.2016 23:08+1А теперь представим, что React, в следующей версии меняет логику вызова
renderи начинает вызыватьrenderвложенных блоков в рамках render'а родительского, а не последовательно, как сейчас. Что будете делать в этом случае? Если я правильно понял, то в этом случае любое изменение приведёт к перерендеру всего App, аcellxтупо станет лишним оверхедом.
vintage
19.10.2016 01:00+1При использовании OORP сам реактовский рендерер становится оверхедом.
RubaXa
19.10.2016 09:16Эта статья про «React + ___», так что правильный ответ: OORP (даже не знаю что это) является оверхедом при использовании с React.
vintage
19.10.2016 09:33Объектно Ориентированное Реактивное Программирование. То, что реализует cellx.
babylon
23.10.2016 16:54Может это и РП, но только не ООП. В чём объектность? В противном случае достаточно было бы простого траверсинга сверху вниз. Чего не наблюдается.
vintage
23.10.2016 17:43В том, что "реакции" (те самые реактивные переменные) не в воздухе висят, а принадлежат объектам. И изменение состояния одного объекта реактивно отражается на других объектах. В том числе приводит к созданию и уничтожению других объектов обладающих реакциями.
babylon
24.10.2016 17:09Это уже зависимости. У меня некоторое де-жа-вю. Как будто ты на флеш форуме в 2008г. Ничего не меняется в датском королевстве.
indestructable
19.10.2016 00:16+5Основная идея Реакта — это быстрое обновление представления по новым (независимым от существующих) данным. В идеале — берем данные, рендерим вью, меняем данные (как угодно), даем вью — получаем оптимальное (ну или хотя бы достаточно быстрое) обновление представления.
Для меня в этой концепции самое привлекательное — это максимальная изоляция состояния и представления друг от друга, и связь между ними по четким, минимальным и контролируемым каналам. Тот же редакс хорош не тем, что он понятный или простой, или удобно ложится на джаваскрипт — он запутанный, особенно с непривычки, требует усвоения новых паттернов, и сложен для выражения в недофункциональном джаваскрипте.
Но при этом всем он вообще не требует вью для своей работы. Он не требует библиотек, наследования, использования своих сервисов или своей реализаций коллекций. И это прекрасно, а вдвойне прекрасно, что их там некуда впихивать (иначе кто-нибудь их туда точно впихнул бы).
Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Strate
19.10.2016 11:29Идея то идеей, однако в большом развесистом приложении со сложными взаимосвязями рано или поздно всё придёт к тому, что на каждый чих будет вызываться render каждого компонента. А их много. Причём в резальтате ререндера не происходит обновления DOM — то есть ререндер был вхолостую. mobx/cellx позволяют эту порблему решить точечно дёргая рендер только тех компонентов, которые действительно надо обновить.
Да, в redux того же можно достичь, но с большим объёмом ручной работы, с использованием всяких reselect, с хитрыми shouldComponentUpdate и так далее.RubaXa
19.10.2016 11:58+2По моему это само обман, добавить
shouldComponentUpdateравносилен прописыванию всех этих@observer,@computedи т.п. Притом ещё в подавляющем случае, можно просто сделать декоратор, который будет проверять изменения всех props.
P.S. Не стоит записывать меня в защитники React, редко использую, но смотря на примеры с реактивностью и «перерендер на каждый чих», я выбираю второе.
lega
19.10.2016 12:27Притом ещё в подавляющем случае, можно просто сделать декоратор, который будет проверять изменения всех props.
Дак это же diry-checking (тот самый что в angular.js), только в итоге будет 2 dirty-checking'a, один на данные, другой на vdom.RubaXa
19.10.2016 12:41Воу-воу, при сравнении vdom нет dirty-checking, там строгая проверка, фиксированного списка свойств, в отличии от ангуляра с его ограниченным (если не ошибаюсь)
deepEqual. Во-вторых, вы так пишите, как будто, это что-то плохое, взять и проверить фиксированный набор свойств, которые описаны вpropTypes.lega
19.10.2016 13:03+1при сравнении vdom нет dirty-checking, там строгая проверка, фиксированного списка свойств, в отличии от ангуляра с его ограниченным (если не ошибаюсь) deepEqual.
DeepEqual там не часто, обычно идет проверка списка свойств. В vdom хоть и узкий список свойств, но проверять приходиться все* дерево, что и делает его dirty-checking.
Во-вторых, вы так пишите, как будто, это что-то плохое
Нет, я за, он работает быстро.
Strate
19.10.2016 12:50Нет не равносилен, потому что shouldComponentUpdate блочит ререндер всего поддерева компонента, а mobx/react позволяет доставлять точечно обновления куда следует.
https://twitter.com/mweststrate/status/718444275239882753 — тут можно посмотреть сравнение туду-листа написанного с использованием redux vs mobx. С тем же mobx приходится писать сильно меньше обслуживающего кода, и получаем из коробки производительность.
https://habrahabr.ru/post/304340/ — здесь отличный пример того, о чём я говорю. Посмотрите в статье бонусный совет в самом конце.
RubaXa
19.10.2016 12:54Вы меня не поняли, это ответ на:
Да, в redux того же можно достичь, но с большим объёмом ручной работы, с использованием всяких reselect, с хитрыми shouldComponentUpdate и так далее.
Я к тому, что определить
shouldComponentUpdateне сложнее, чем расставить все эти@observerи т.д.
RubaXa
19.10.2016 13:02+1Теперь про бенчмарк и mobx.
Вы смотрели его исходники? Заметили, как именно пришлось написать ему приложение, чтобы всё раком не встало. В итоге компоненты, которые должны просто получать «голые» данные и быть независимыми и универсальными, передают от компонента к компоненту ссылку на
store. И такое происходит на каждом уровне, он даже вTodoItemпередаёт неid,title,completedили просто<TodoItem {...todo}/>, а именноtodo={todo}.
Вот и получается, что вместо написания простого и понятного приложения, человек борется с реактивностью.
Strate
19.10.2016 15:09Проброска в компоненты store — всего лишь один из вариантов написания приложения. Вы можете пробрасывать либо через контексты (как и делает react-redux в его функции connect), либо вы можете оставить store только в рутовом компоненте, но пробросить во внутренние компоненты чистые данные/коллбеки и всё будет работать.
RubaXa
19.10.2016 15:29Проброска в компоненты store — всего лишь один из вариантов написания приложения
Это костыль, правильно, это в app собрать данные, и распихать их по компонентам через
props. Но в примере mobx, абсолютно все компоненты завязаны на конкретныйstoreс его конкретными свойствами, да так, что реюзабельность компонентов стремиться к0.
оставить store только в рутовом компоненте, но пробросить во внутренние компоненты чистые данные/коллбеки и всё будет работать.
Вот как только вы это сделаете всё ваше приложение замкнется на самой высшей точке
App.renderи любое изменение будет приводить к его перерендеру. Именно поэтому, автор этого «бенчмарка» так старательно избегает обращения к getter'амstore.
Кроме этого, в этом коменте я уже писал, что стоит React'у поменять логику вызова
render, так даже передачаstoreне поможет.Strate
19.10.2016 15:39Вот как только вы это сделаете всё ваше приложение замкнется на самой высшей точке App.render и любое изменение будет приводить к его перерендеру.
Именно так и происходит при использовании redux. С mobx — нет. Потому что в нём не меняется store. В нём меняются объекты внтури него. Например при изменении поля
nameу объекта классаTodoобновится только один конкретныйTodoItem, который его отображает. Все соседние не будут изменены, а также сам список тоже. Это будет верно даже если в TodoItem не будет передан (в явном или неявном виде) store. Как раз за счёт реактивности. Должно быть только одно — компонент его отображающий должен быть@observerи всё.
Если вам интересно, я могу как нибудь сделать форк mobx-todomvc и переписать его убрав передачу
storeво все дочерние компоненты, вы увидите что это ничего не изменит.RubaXa
19.10.2016 16:34+1Давайте я за вас сделаю:
- Вот так надо писать, чтобы mobx работал, а не мешал: http://codepen.io/RubaXa/pen/gwQPZK
- А вот так пишут нормальные люди: http://codepen.io/RubaXa/pen/kkQPzP?editors=0110
Но допустим, что с
<TodoItem todo={todo}/>можно смириться и даже убедить себя, что так даже лучше, но что делать, когда нужно сделать динамический текст в кнопке (Add #{XXX})?
Так не выйдет: http://codepen.io/RubaXa/pen/EgOPJW?editors=0010?
Придется сделать
@observer const ButtonTodoAdd = ({todos}) => <button>Add #{todos.length + 1}</button>
И вот придется делать каждый раз, чтобы приручить реактивность.
Strate
19.10.2016 16:49То есть по вашему, необходимость передавать
<TodoItem todo={todo}>— это слишком "ненормально"? Вкусовщина чистой воды, мне вот больше нравится передавать сущности отдельным атрибутом, а не spread-оператором.
Обратите внимание, что все ваши примеры работают из коробки, ни с чем бороться не приходится, динамический текст в кнопке тоже работает. Но для получения большей производительности надо бить приложение на мелкие компоненты, и соблюдать некоторые правила.
В случае с redux для достижения той же производительности придётся писать дополнительный код, а не реорганизовывать существующий.
RubaXa
19.10.2016 17:03Обратите внимание, что все ваши примеры работают из коробки, ни с чем бороться не приходится
Как это не приходится? Всё совсем наоборот, я прекрасно понимаю, как работает Mobx, поэтому написал именно так, иначе бы получил бы полный перерендер. Поэтому каждый мой шаг был обдуман, что и где можно вызывать.
Но для получения большей производительности надо бить приложение на мелкие компоненты, и соблюдать некоторые правила.
Это не так, нужно разбивать не на мелкие компоненты, а на специальные враперы-компоненты, только чтобы угодить mobx.
Представьте простой компонент
Badge, который выводит число, вот чтобы использовать его в mobx, мне придется обернуть его:
const BadgeTodos = ({todos}) => <Badge value={todos.length}/>
и так далее:
const BadgeFooWithBar = ({foo, bar}) => <Badge value={foo.length + bar.length}/>
Вот я и пишу дополнительный код, который нужен только для Mobx.
Strate
19.10.2016 17:51Блин, вам не нужно оборачивать компоненты чтобы угождать mobx. Берите и используйте как привыкли, mobx всё это нормально скушает. Как только у вас появится желание оптимизировать выделяете кусок рендера в отдельный компонент и всё, без селекторов, shouldComponentUpdate и прочего.
RubaXa
19.10.2016 20:46Ох, ну ладно, если вам всё нравится, то кто я такой, чтобы говорить вам обратное, так что всего доброго и хорошего настроения ;]
farwayer
20.10.2016 00:18Да вот в том и дело, что приходится выбирать между хорошей переиспользуемостью компонентов (да-да, чтобы в Badge число передать) и производительностью. Нету гармонии в таком подходе: настроение сразу портится, когда думаешь, что там лишние рендеры отрабатывают. В инструменте, который ты берешь в том числе для того, чтобы их не было.
Не, можно еще костыли писать, как RubaXa предложил — такой немного уродливый аналог selector'ов из redux.RubaXa
20.10.2016 08:33+1Костыли? Теперь так называют официальные рекомендации по оптимизации? Или вы про декоратор? Так это просто ответ на все эти
@computed.
лишние рендеры отрабатывают
Тут такое дело, что создатели реакта много раз уже говорили, что это не проблема, это by design и им всё нравится, он решает ИХ задачи.
farwayer
20.10.2016 11:09+1Если назвать костыли «официальными рекомендациями» — меньшими костылями они от этого не становятся. Или вы не считаете BadgeTodos костылем, который используется только для того, чтобы улучшить производительность? Вместо того, чтобы использовать Badge с числом, приходится писать wrapper.
То есть при использовании mobx выбор такой:
1. Забить на переиспользуемость компонентов и делать TodoItem, вместо ItemWithTitleAndCompleted (суть, что передаются title и completed, а не todo)
2. Забить на лишние рендеры (рендер родительского при изменении только title)
3. Писать wrapper'ы, которые обворачивают простые компонеты (TodoItem -> ItemWithTitleAndCompleted). имхо костыль.
>> Тут такое дело, что создатели реакта много раз уже говорили, что это не проблема
Это не проблема, когда пару десятков компонентов. А вот когда их сотни и больше — уже не круто. Выполнение функций рендера и сравнение virtual dom тоже не бесплатно, поэтому делать это на каждый чих неправильно. Иначе shouldComponentUpdate не существовало бы.RubaXa
20.10.2016 11:23А вот когда их сотни и больше — уже не круто.
Значит вам не подходит React, вот и всё. Я вот не использую его именно по этой причине и mobx никак не спасет, если для вашего проекта типовая операция это полное обновление сразу более 1К элементов, даже наоборот, только мешать будет.
Выбирайте инструмент под задачу, пишите инструмент под задачу, а не как в приведенной статья про react-konva, в которой человек на ровном месте создал себе проблему и героически решал её, а мог бы взять чистую konva и всё, без Redux, Mobx и т.п. Я не понимаю, как можно было сравнивать Redux и Mobx, Redux же не про рендер, он про dataflow и инструментарий вокруг него. Render — это React.
farwayer
20.10.2016 11:55>> если для вашего проекта типовая операция это полное обновление сразу более 1К элементов
Так в том и дело, что обновляется всего один элемент. mobx как раз и заточен на то, чтобы сделать точечный рендер только тех элементов, которые зависят от измененных данных.RubaXa
20.10.2016 12:02«Полно обновление», это когда один набор даных меняется на другой, понимаете? Тот же пример с todos на mobx, там не просто так акцентируют внимание на изменении
todo, но обходят стороной фильтр поcompleted, потому что он приводит к перендеру всего списка.
Strate
20.10.2016 11:01С селекторами в redux получается точно такой же непереиспользуемый код, но вместо простой обёртки (если она действительно нужна), приходится подключать компонент к стору и писать селекторы.
Конечно каждый выбирает что ему больше по душе, мне оказалось больше по душе написать обёртку.
P.S. В mobx есть ещё одна плюшка — отсутствие необходимости нормализовывать стейт, вместо этого можно хранить сложные графы объектов предметной области и не париться.
farwayer
20.10.2016 11:36В redux это выглядит более естественно: есть стор — достаем из него нужные данные.
В mobx: есть данные, но напрямую мы их передавать в компонент не будем — нужна обертка, чтобы dereference случился позже и было оптимально по производительности.
mobx (и cellx, конечно) хороший инструмент, но эта его особенность мне не нравится. И это скорее всего не поправишь никак.
Riim
19.10.2016 15:38+2Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Да! Полностью согласен. Проблема действительно есть, детально её можно разложить по следующим пунктам (первый малость не в тему, но он тоже нужен):
1) Ренейминг. Сервер присылает
fnameиlname, а я хочу нормальныеfirstNameиlastName, я не хочу подстраиваться под правила нейминга на сервере и я не хочу на каждый чих идти и договариваться с кем-то из беков, пусть даже они сразу идут навстречу.
2) Вот пришли данные пользователя и есть класс пользователя (с кучей реактивных полей), я создаю его экземпляр и нужно переписать данные в него. Если считать, что первый пункт как-то решён, то первая мысль, написать функцию
setData:
function setData(instance, data) { for (let name in data) { instance[name] = data[name]; } }
Но не всё так просто, далеко не всегда данные в полях просто числа и строки, там часто лежат экземпляры других типов. И вот красивые вызовы типа
setData(user, usedData)начинают превращяться в какой-то такой ужас:
setData(user, { ...userData, father: setData(father, userData.father) });
Причём всё это происходит постоянно и в заметно большем колличестве.
3) Нужно постоянно конвертировать массивы и хеши в их наблюдаемые аналоги (
cellx.listиcellx.map). Этот пункт похож на предыдущий, их можно слить в один и общий пример получается примерно таким:
setData(user, { ...userData, friends: cellx.list(userData.friends.map(friendData => setData(new User(), friendData))) });
4) Почему в предыдущем пункте мы просто создаём новые экземпляры друзей? Что если данные какого-то друга уже запрашивались, где-то используются (есть экземпляр этого пользователя) и новые данные нужно слить в уже существующий экземпляр? Например, есть основные данные пользователя для его маленькой карточки, а остальные данные запрашиваются отдельно при заходе на его анкету. Что-то подобное происходит постоянно и для многих типов приложения где-то в хранилище приходиться заводить хешики в которые по айдишникам складывать существующие экземпляры, а потом постоянно писать так:
setData(store.userMap[userData.id] || (store.userMap[userData.id] = new User()), userData);
Это тоже бесит.
5) Кто сказал, что всегда нужно просто брать данные и тупо записывать их в какие-то поля? Что если записывать их нужно как-то иначе? Идеальный пример тут — бесконечная подгрузка списков — нужно не просто заменить существующий список новым, а дополнить существующий список новыми записями.
Вот, вроде ничего не забыл. Я очень рад, что появился редакс и показал все эти проблемы с конвертированием данных в типы. Раньше всё это воспринималось как само собой разумеющееся и когда я пытался про это говорить и придумывать какие-то решения, мне обычно говорили что-то про какие-то мельницы и всё в этом духе.
Теперь про решение, да, редакс с его чистыми данными по большей части не требует никаких решений и в этом его плюс, но он же заставляет отказаться от плюшек реактивного программирования. Если перечисленные проблемы реально автоматизировать до уровня когда они не будут напрягать, то почему бы так и не сделать, сохранив при этом возможность использовать РП.
Я просто расскажу как всё устроено в текущем проекте, это уже не первая моя попытка всё это решить и пока похоже наиболее удачная.
По пунктам, первый пункт вполне актуален и при использовании редакса, и сразу вопрос: почему фиксить нейминг нужно именно при конвертировании данных в типы или, в случае редакса, при их записи в хранилище? В любом (или почти любом) приложении есть слой доступа к удалённым данным, он обычно не обсуждается при обсуждении архитектуры, но он есть, у меня он называетсяproxy(чаще называютprovidersили как-то так), почему бы не фиксить нейминг в нём? Он лучше для этого подходит, данные он при этом будет возвращать по прежнему чистые, никаких типов, кроме того, сразу после этого слоя можно вообще забыть о существовании какого-то другого нейминга. У меня в папкеsrc/proxyлежит папкаconvertersв которой файлики типаconvertUserData.js, через которые пропускаются успешные ответы сервера. Типичное содержимое:
// @flow export default function convertContactMediaCompanyData(data: { ID: string, format: { name: ?string }, name: ?Array<string> }) { return { id: data.ID, formatName: data.format.name, names: data.name && data.name.length ? data.name : null // Массив имён, на сервере не любят добавлять `s` в конце имён коллекций }; }
Если есть сложные подданные, то создаётся ещё подобный файл и используется в текущем:
tags: data.tag && data.tag.length ? data.tag.map(convertContactTagData) : null,
Что бы не дублировать типизацию в текущем конвертере поле
tagsможно описать какArray<Object>, а уже вconvertContactTagDataрасписать подробнее.
При таком подходе удаётся убить сразу двух зайцев: пофиксить нейминг и, используя модуль babel-plugin-tcomb сразу провалидировать ответ сервера, тайпскрипт тут не подойдёт, он верит программисту, а при работе с сервером программист не может верить сам себе, tcomb же подставляет реалтаймовые проверки. Это позволяет отлавливать косяки данных сервера не где-то в слое представления и пол дня тратить на понимание причины, а в самом их корне. Конечно же сборка настраивается так, что реалтаймовые проверки подставляются только для dev-сборки (иначе продуктовый бандл сильно раздувается, а для dev-версии это норм и этого достаточно для получения нужного результата).
Дальше следующие три пункта я решаю модулями @riim/statex и @riim/typify-data. Я не планировал их в ближайшее время кому-то показывать и там нет описания, поэтому опишу здесь. По сути это очень продвинутая версия
setData.
new StateX({})создаёт корневое хранилище, первый аргумент — карта имён на классы типов, на примере будет понятнее:
import StateX from '@riim/statex'; import App from './types/App'; import User from './types/User'; // ... let state = window._state = new StateX({ App, User, // ... }); export default state;
Зачем карта будет понятно чуть позже. Дальше метод
push— принимает чистые данные (ну почти, typifyData их чуть-чуть портит) и обходя их рекурсивно решает пункты 2-4:
- массивы оборачивает в
cellx.list - в объектах ищет поле
__type, если нет, то оборачивает вcellx.map, если есть, находит в карте переданной при вызовеStateXсоответствующий данным класс. Хешики из пункта 4 строятся всегда автоматически для каждого типа: смотрит полеid, ищет его в хешике, при отсутствии создаёт инстанс и запоминает там. - если
idнет, значит этот тип единичный в приложении, скажем это тип описывающий раздел приложения "Настройки".
Метод
get— возвращает инстанс по типу и, если есть, айдишнику:
this.user = state.get('User', this.props.userId);
idприходит с сервера, теперь остаётся только добавить__type. Добавлять его в конвертерах мне кажется не совсем хорошо, proxy должен возвращять чистые данные, а__type— это метаинформация в данных о том, что это за данные. Добавлять их как-то так:
store.push({ __type: 'User', ...userData });
тоже не хочется, при большей вложенности будет неудобно:
store.push({ __type: 'User', ...userData, friends: userData.friend.map(friendData => { __type: 'User', ...friendData }) });
по сути это возвращение к тому от чего только что ушли. И вот тут как раз нужен
typifyData, он принимает первым параметром совсем сырые данные и по второму аргументу добавляет поле__typeв них, предыдущий пример на нём:
store.push(typifyData(userData, { '': 'User', 'friends': 'User' }));
"Проваливание" в массивы происходит автоматически и как-то отдельно в ключе передаваемого объекта не описывается.
Можно ещё посложнее:
store.push(typifyData(userData, { '': 'User', 'tags': 'UserTag', 'friends': 'User', 'friends.tags': 'UserTag' }));
Ну и последний пункт. Опять же первая мысль, придумать ещё что-то типа typifyData добавляющее метаинформацию к данным о том как их использовать, а
#pushнаучить этому. Плохо то, что вариантов использования очень много, всему#pushне научишь, тут можно решить намного красивее и универсальнее. В статье где сравнивается cellx-vs-mobx есть про опциюput, вот она то и нужна, просто покажу как можно решить с бесконечной прокруткой:
@observable contacts = void 0; @observable total = void 0; @observable({ put(value, push) { if (value) { if (this.contacts) { this.contacts.addRange(value); } else { this.contacts = value; } } push(value); } }) nextContacts = void 0;
То есть на уровне конвертеров переименовываем
contactsв какой-нибудьnextContacts, в классе же полеnextContactsсохраняет их себе (push(value)), но перед этим дописывает в соседнийcontacts. Тут можно и без observable свойства, nextContacts может быть обычным сеттером, но тогда от него нельзя будет вычислять другие ячейки, мало ли зачем такое понадобиться. Подобно можно любым образом нестандартно записывать что-то в поле черезStateX#push.
Вот как-то так я и упарываюсь :). Знаю, что это Хабр и сейчас набежит куча экспертов, которые разнесут всё в пух и прах и смешают с авном, не стоило это писать, я просто вижу как это работает, кода получается явно меньше чем даже с редаксом, нет уже этих многоуровневых
{ ...data, prop: { ...subdata, prop: { ...subsubdata, ... } } }и вся эта ранее постоянно напрягающая конвертация данных уже вообще не заметна, плюс плющки РП и хорошая производительность.indestructable
20.10.2016 01:16Спасибо за подробное описание. За годы работы выработал в себе интуитивное правило, которое только сейчас осознал: все библиотеки отстой, и чем четче граница между ними и бизнес-кодом с данными, тем лучше.
- массивы оборачивает в
RubaXa
20.10.2016 13:09+3@Strate Смотрите, я сейчас специально ещё раз посмотрел на пример в статье и заметил типичную реактивную проблему, а именно вместо уменьшения количества рендеров, мы получаем лишние. Для визуализации проблемы, достаточно добавить:
console.log('TodoApp#render')иconsole.log('TodoItem#render')
Запустив пример, вы увидите:
- TodoApp#render
- (3) TodoItem#render
А теперь нажмите на чекед:
- TodoItem#render
- TodoApp#render
- (3) TodoItem#render
Вам может показаться, что пример можно переписать, добавив врапперы в стиле Mobx, но это не так, проблема останется, вот из-за этой строчки.
Всё дело в
key, как толькоtitleизменится у N-элементов, мы опять получим N лишних рендеров, а потом финальный перендер всего списка. Конечно можно завести полеid, а лучше всего ещё его сделать неobserveble, только так можно решить проблему окончательно.
Я не эксперт, просто задаю вопросы смотря на подобный код, так что очень хотелось бы услышать об опыте Riim, часто ли бывают такие ситуации и что с ними делать, ну или best practices чтобы не стрелять себе в колено?!
P.S. Ещё бы хорошо получить ответ на мой первый комментарий.
Riim
20.10.2016 14:03услышать об опыте Riim
мой опыт в том, что реакт — какашка)). Я написал о нём только потому что многим он нравится. Все проблемы, которые вы обсуждаете выше я пытался решить в своей реализации vdom и могу сказать, что вот это
создатели реакта много раз уже говорили, что это не проблема, это by design и им всё нравится
не правда, им это нифига не нравиться, они просто не могут с этим что-то сделать, так как там реально тупик, что только я не пробовал, в том числе вообще уходить от виртуальной составляющей, продублирую здесь свой другой комментарий:
----
Плюс у меня есть свои реализации как VDOM, так и патчера без V составляющей. Мне тоже вся эта идея изначально очень нравилась и нахватавшись всяких кейсов вроде описанного выше я попытался исправить их в своём варианте, поняв, что это нормально сделать не получается, начал пилить morph-element, идея была такой: сравнение строк — идеально быстрая операция, причём не зависит от длинны строки, даже при очень длинных и почти совсем одинаковых строках сравнение происходит сверхбыстро где бы не находилось различие. Дальше вместо подстановки разметки дочернего компонента за счёт вызова его как функции, родитель должен был генерировать кастомные элементы разметка которых разворачивалась уже в attachedCallback (ныне connectedCallback) (он синхронный, полифилится на MutationObserver не синхронно, но это тоже удалось решить). Что это давало? Получалось, что каждый компонент генерирует только свой собственный контент, но не контент потомков, то есть при первой генерации можно просто запомнить эту строку и при последующей сравнивать не два огромных объекта со всем контентом потомков, а две относительно короткие строки, что в 100500 раз быстрее. Ну и естественно не перегенерировать контент потомков при равности контента родителя с предыдущим вариантом. То есть лишняя перегенерация всё же происходила (родитель), но уходила не на всю глубину, а максимум на один уровень. Такой подход решал некоторые проблемы VDOM, но не все и в целом патчинг с реального DOM (без виртуальной составляющей) всё же получается медленней, как бы я не пытался его оптимизировать и что бы там не говорил разработчик оригинального morphdom.
В общем, пока я здесь в тупике, а все другие варианты, что я вижу, предлагают костыли вроде:
добавляем dirty флаг
используем внутренние часики и проверяем по дате модификацииА хочется то нормальный фреймворк, который позволяет просто спокойно кодить не расставляя эти самые костыли по всему коду.
Сейчас я для себя пришёл к выводу, что VDOM — тупиковая идея, но я не исключаю, что ошибаюсь и возможно ещё вернусь к ней))
Пока вернулся к точечным биндингам, тут тоже не всё в идеале, но всё же явно лучше.
----
Вот такой вот опыт. Сейчас я использую свою библиотеку для view, там классические биндинги и лишних рендеров примерно ноль. С ней ещё много работы впереди.
Ещё бы хорошо получить ответ на мой первый комментарий.
А теперь представим, что React, в следующей версии меняет логику вызова renderВ этом случае сломается не только
cellx-react, многое должно сломаться и вряд ли они будут так круто что-то менять.
vintage
20.10.2016 13:55я сейчас специально ещё раз посмотрел на пример в статье и заметил типичную реактивную проблему, а именно вместо уменьшения количества рендеров, мы получаем лишние.
Всё же проблема Реакта, а не реактивная. Заточенный под реактивность рендерер лишних действий производить не будет.
RubaXa
20.10.2016 15:09Попробую псевдокод написать:
items = [{value: 'foo'}] rootLevel() var x = items.length ? items[0].value : 0; console.log('root:', x) items.forEach(item => subLevel(x, item)) subLevel(x, item) console.log(`item: ${x} + ${item.value}`) rootLevel() // root: foo // item: foo + foo items[0].value = 'bar' // item: foo + bar // root: foo // item: bar + bar
Где и почему я ошибся?
Riim
20.10.2016 16:51http://jsbin.com/vexugulala/1/edit?js,console
// root: foo // item: foo + foo // root: bar // item: bar + barRubaXa
20.10.2016 17:35Эээ, нееее, так не пойдет, subLevel же тоже должен быть реактивным :]
Riim
20.10.2016 17:43То же самое: http://jsbin.com/fucopaleri/edit?js,console
RubaXa
20.10.2016 17:54Давайте попробую текстом описать. Смотрите, есть два уровня:
root, в немsub, root принимает массив элементов и итерируется по нему вызывая sum, которому передает value первого элемента массива и сам элемент. Дальше я ожидаю, что при изменение первого элемент, произойдет обновление начиная с root, но если обновить любой другой, то должен обновиться только связанныйsub, возможно такое?Riim
20.10.2016 17:59Ага, понял, в прошлый раз не правильно написал, вот так должно быть: http://jsbin.com/fuhepiboci/edit?js,console
Вывод:
root: foo item: foo + foo item: foo + bar root: bar item: bar + bar
Первые три — инициализация, остальное, вроде то, что ожидается)
RubaXa
20.10.2016 18:08Вот теперь правильно и проблема на лицо: http://jsbin.com/pixuqijinu/1/edit?js,console
~~~ START ~~~ root: foo item: foo + foo ~~~ CHANGE ~~~ item: foo + baz root: baz item: baz + bazRiim
20.10.2016 18:21На самом деле всё правильно, rootLevel читает
items[0].valueи следовательно подписывается на него, если всё же нужно неправильно, то нужно как-то прочитать его без автоматически срабатывающей при этом подписки. Раньше для этого можно было при чтении передатьfalse, потом я убрал эту возможность, вроде нигде не пригождалась, поэтому сейчас только читать скрытое поле: http://jsbin.com/cubipigaqe/1/edit?js,console
Могу вернуть опцию, не проблема)RubaXa
20.10.2016 18:27Всё правильно, что он подписался, а вот дальше неправильно (если быть честным). Надеюсь, что когда-нибудь, появится решение, которое разрулит данную ситуацию и в одном случае обновит начиная с
root, а в другом конкретныйsub.Riim
20.10.2016 18:30Я правильно понимаю, что в root под подпиской на
items[0].valueподразумевается подписка на сам список?RubaXa
20.10.2016 18:37Смотрите http://jsbin.com/zaserej/edit?js,console а теперь почитайте мои коменты к выводу:
~~~ START ~~~ // Тут всё правильно root: foo item: foo + foo item: foo + bar ~~~ CHANGE: bar -> baz ~~~ // Супер, как и ожидалось! item: foo + baz ~~~ CHANGE: foo -> oof ~~~ // И... item: foo + oof // <------ эх, ты лишний! root: oof // Далее всё норм item: oof + oof item: oof + bazRiim
20.10.2016 18:46А точно ли он лишний? Реакт ведь не создаёт новые инстансы компонентов для элементов списка при повторном рендере, а как-то совмещает их с предыдущими. Если так, то лишний кто-то из двух последних, а другой из них должен начинаться с 'foo'. Вроде так, нет?
RubaXa
20.10.2016 18:52Да выбросите вы этот Реакт из головы, он тут совсем не причем.
Я говорю про реактивное программирование в целом. Как не посмотри на этот пример, вычисление лишнее само по себе, я понимаю почему оно происходит, но оно не нужно, данные устарели уже и вычисленное значение будет не актуальным, да и потом всё равно следует обновление начиная с
root.
RubaXa
20.10.2016 18:59Вы если что простите и не думайте, что решил докопаться и высосал проблему из пальца, просто vintage утверждает, что это проблема React, но это не так, лишний рендер в примере из-за реактивности как таковой.
Riim
20.10.2016 19:07Да не, нет всё таки проблемы)) Ячейки создаются в самой формуле при каждом её расчёте, это же вообще никак не нормально. Я даже не знаю к какой жизненной ситуации это можно прилепить и даже если найдётся такая ситуация, то там такое поведение скорее всего окажется как раз ожидаемым. Вот, я сделал что бы ячейки от первого расчёта подцеплялись в последующих: http://jsbin.com/hokurejije/1/edit?js,console, теперь всё правильно)
RubaXa
20.10.2016 19:13Теперь совсем неправильно ;]
Сейчас~~~ CHANGE: foo -> oof ~~~
item: foo + oof // тот самый лишний
root: oof // окей, root обновился
// А где теперь свежие значения
// - oof + oof
// - oof + bar
Riim
20.10.2016 19:23тот самый лишний
неа, он обновился первым, потому что root зависит от него, он (sub) должен вычислиться раньше чтобы дать ему (root) актуальное значение (в данном случае оно не используется), иначе сам root вычислится от старого значения sub, а только потом sub обновится.
А где теперь свежие значения
fooзапомнился в замыкании при первичном создании ячейки, тут уже проблема проброски данных (и вполне решаемая), а не РП.RubaXa
20.10.2016 19:30Я честно не понял о чем вы, но добавил `map` и `return`, теперь ячейки возвращают какие-то полезные данные http://jsbin.com/vupika/edit?js,console и всё хорошо, пока до `foo => oof`.
Riim
20.10.2016 19:52Ну смотрите, есть три ячейки зависимые в таком порядке:
A -> B -> C, изменяем A. Кто должен сперва вычислится B или C? Если сперва вычислится C, а потом B, то C прочитает устаревшее значение от B и вычислится неправильно. Примерно тоже самое и здесь. Проблема на самом деле намного хитрее, в статье про атомы vintage толково её описал (начиная с2. Каскадное непротиворечивое обновление значений)
пока до
foo => oofв выводе сейчас вроде всё как надо.
RubaXa
20.10.2016 20:52Оххх, похоже мы в тупике. Я уже отвечал, что в рамках тех реализаций РП, которые я видел, они максимум могут выдать вот такую картину. Я прекрасно понимаю почему и какие зависимости были образованы, но это не отменяет того, что один шаг там лишний.
Riim
20.10.2016 21:10А что за ситуация в которой понадобилось при каждом расчёте создавать ячейки? Это какая-то реальная ситуация или просто ради эксперимента?
vintage
20.10.2016 23:08+2Не обязательно при каждом. У этой проблемы есть и другие, более неприятные, проявления. Например, это паразитное вычисление может обращаться к уничтоженным объектам и вызывать падение. Поэтому я отказался от обновления снизу вверх в пользу обновления сверху вниз. В данном примере будет следующая последовательность действий:
- обновили значение первого элемента.
- инвалидировалось значение корневой вьюшки. так как она корневая, то запланировала отложенное обновление.
- инвалидировалось значение первой вьюшки.
- сработало отложенное обновление корневой вьюшки.
дальше всё как и при инициализации.
- обновили значение второго элемента.
- инвалидировалось значение второй вьюшки.
- значение корневой вьюшки помечено как требующее проверки. так как она корневая, то запланировала отложенную проверку.
- сработала отложенная проверка корневой вьюшки.
- корневая вьюшка проверила первый айтем на актуальность состояния.
- корневая вьюшка проверила первую вьюшку на актуальность состояния.
- корневая вьюшка обнаружила вторую вьюшку в неактуальном состоянии.
- вторая вьюшка обновила своё состояние.
- так как значение второй вьюшки не изменилось (изменилось лишь побочное действие), то корневая вьюшка решила, что её состояние актуально и обновляться не стоит.
vintage
20.10.2016 22:44+2http://jsbin.com/pomijoyiwu/edit?js,console
"~~~ START ~~~" "root: foo" "item: foo + foo" "item: foo + bar" " ~~~ CHANGE: bar -> baz ~~~" "item: foo + baz" " ~~~ CHANGE: foo -> oof ~~~" "root: oof" "item: oof + oof" "item: oof + baz"RubaXa
21.10.2016 08:40Во! Вот это уже успех!
Смело вычеркиваем `$mol_atom` из типичных реализаций РП ;]
Riim
21.10.2016 11:34@vintage, я правильно понял, что в схеме
A -> B -> Cпри изменении A сперва вычислится C, потом B и если значение B при этом изменится, то C посчитается ещё один раз?
Добавил чтобыsubвозвращал выводимое значение, появилось что-то лишнее: http://jsbin.com/mabozejudi/1/edit?js,consolevintage
21.10.2016 15:47+1Нет, там две фазы: сначала всплытие проверок до корня, а потом уже обновление инвалидированных атомов в правильном порядке. У каждого атома есть 3 состояния: actual, obsolete, checking. Если атом obsolete, то при обращении к нему происходит обновление. Если checking, то предварительно актуализируются его завсимости и если хоть одна при этом поменяется, то она сделает его obsolete, что приведёт к его обновлению.
Ничего лишнего, rootLevel у вас зависит от значений возвращаемых subLevel.
" ~~~ CHANGE: bar -> baz ~~~" "item: foo + baz" // вычислили второй сублевел "root: foo" // вычислили корень "item: foo + foo" // создали новый первый сублевел и вычислили его "item: foo + baz" // создали новый второй сублевел и вычислили его // уничтожились старые сублевелы
Чтобы не пересоздавать атомы — их нужно кешировать.
Riim
21.10.2016 17:07Кажется разобрался, когда меняется A все кто от него зависит помечаются как возможно требующие перерасчёта, дальше читается самый вложенный, в
A -> B -> Cэто C, в нём сперва срабатывает егоconsole.logи следом читается B, B при чтении понимает, что он возможно устарел и не отдаёт запомненное значение, а тоже начинает перерасчитываться, срабатывает уже егоconsole.log. В общем, всё работает подобно обычным функциям. Так можно сказать? Или как-то ещё хитрее?))Riim
21.10.2016 17:09Непонятно почему изменился порядок расчёта после push: http://jsbin.com/xebozudala/1/edit?js,console? Видимо ещё хитрее)
vintage
21.10.2016 20:34Почти, только C перед тем как запускать свой расчёт, просит В актуализировать своё значение. И если В изменит своё значение после этого, то С поймёт, что его значение устарело и перевычислит себя. А если В не изменит значение, то С не будет перевычисляться, так как ни одна из его зависимостей фактически не поменялась. Таким образом получается как бы перескок вглубь, через промежуточные вычисления. Разумеется, такое преобразование делается в допущении, что результат работы функции зависит лишь от других реактивных переменных или констант, но не от нереактивного мутабельного состояния.
Riim
22.10.2016 01:55… А если В не изменит значение, то С не будет перевычисляться ...
ну да, то что там защита от лишних расчётов это понятно. Я экспериментировал с таким вариантом, не ради другого поведения, а интересно было, что по скорости из него можно было выжать. Получалось не очень, много потерь на обходе для инвалидации ячеек перед их вычислением. Сейчас у меня похожим образом работает пассивный режим, но без этого обхода (его и не может быть, сам смысл пассивного режима в отсутствии ссылок от родителей к потомкам, чтобы GC мог забирать такие ячейки, а значит и обходить просто не по чему). Сделано немного иначе: есть общая для всех переменная, которая при каждом проходе расчёта инкрементится и все попавшие в этот обход ячейки получают это значение. У оставшихся ячеек это значение уже отстаёт, это и делает их устаревшими. Минус в том, что устаревшими могут случайно становиться лишние ячейки, ну и естественно случаются лишние расчёты, но тут уже ничего не поделать, при отсутствии ссылок обойти и точно пометить кто устарел, а кто нет, не выйдет. Для пассивного режима этого хватает, для основного конечно не подойдёт.
vintage
22.10.2016 10:26Между скоростью и корректностью, лучше выбирать корректность. К тому же, такой подход позволяет избавиться от перехвата исключений. Хотя, я всё равно их перехватываю, но уже для распараллеливания асинхронных запросов.
А в чём практический смысл пассивного режима? Ведь он приводит к тому, что и вычисления все нужно проводить и ячейки все создавть.
Если потомок имеет ссылку на родителя, то в чём проблема пометить родителя устаревшим? Ссылка от родителя к потомку нужна для уничтожения подписок. Или в пассивном режиме вообще никаких ссылок нет?
Riim
22.10.2016 11:28Между скоростью и корректностью, лучше выбирать корректность
Если потомок имеет ссылку на родителя, то в чём проблема пометить родителя устаревшимну тут выбирать не приходится, если меняется A и B содержит ссылку на A, то при обработке изменения толку мне от этой ссылки никакого, так как я в точке A.
А в чём практический смысл пассивного режима? Ведь он приводит к тому, что и вычисления все нужно проводить
не нужно, пассивные ячейки перестают вычисляться при изменениях и вычисляются только непосредственно при чтении (обычно этого не происходит и пассивные ячейки либо умирают, либо снова становятся активными), да и то, только если что-то менялось. Плюс ячейки можно воспринимать как сущности, а не как сущности-обработчики, то есть не нужно помнить о том, что саму ячейку тоже нужно от кого-то отцепить, достаточно не забыть снять обработчики с неё самой.
RubaXa
23.10.2016 09:38+1Не знаю, кто есть живой в этом посте, но если вам не сложно проплюсуйте карму vintage и Riim. Я понимаю, что многим бывает не нравится назойливость и их манера вести диалог (без обид парни), но они наверно единственные, кто серьезно исследует тему настоящего РП (на хабре уж точно), а не тормозных стримов в духе Rx. Поэтому я хотел бы видеть ещё статьи от них, с выводами которых можно не соглашаться, но проблемы и идеи которые они озвучивают близки мне, а то чтения «Готовим Реакт», «Полное руководство по Реакт», «Ехал Реакт, через Redux, Реакт, Реакт» в которых нет абсолютно ничего нового, уже выть хочется.
xGromMx
Сравни свой cellx со скоростью https://github.com/cujojs/most