нет возможностей нет проблем

великие слова)

sample и guard написаны на javascript, поэтому разумеется любая не особо упоротая система на этом языке способна воссоздать их работу

включая mobx, redux и knockoutjs

У меня так баги в коде чинили. Прост удаляли код с багом. Нет кода - нет бага = )

нинада, я не хочу больше слышать о третьем, боль которая не проходит)

но есть огромная разница между возможностью существующей из коробки, тщательно интегрированной со всей концепцией, и тем что нужно каждый раз писать самому

собственно тут guard оч хороший пример — его можно создать на базе сэмпла минут за 15, просто объедините данные из source и filter стора, сделайте проверку и разверните результат обратно. ну и в один момент я просто понял что это должно быть доступно сразу

и это и есть развитие — когда то, что раньше требовало усилий, становится легче в использовании

я видел что sample и guard необходимы для выхода на новый уровень, поэтому мне потребовалось сделать стейт-менеджер вокруг полноценного графа, если же автор считает что можно прожить и без них, то его вполне устроит дерево, как в мобиксе

просто создать стейт менеджер вокруг дерева подписок на порядок проще, чем вокруг полноценного графа

я целый год ждал что кто-нибудь займётся этим вместо меня, но в итоге понял что из этого локального максимума стейт-менеджеров придётся вырываться мне самому)

👍

Ну это и логично, mobx и не решает задачи которые решает эффектор - он не предлагает возможностей юзеру выстраивать цепочки обработки событий (реакции на изменение переменных внутри которых можно менять другие переменные которые в свою очередь вызовут еще какие-то реакции и т.д)
Все что предлагает mobx - это всего лишь кеширование вычислений (ну и реакции чтобы обновить компоненты или выполнить другие сайд-эффекты но ни в коем случае не для изменения других переменных мобикса) и совершенно правильно что при вычислении любое чтение переменной должно вызывать подписку на эту переменную (потому что результат вычисления теперь зависит от значения переменной и нужно перезапустить вычисление когда эта переменная изменится)

кстати вся эта история наводит на мысль что CAP-теорема существует для любых систем состояний включающих в себя граф — географический или в памяти v8 уже даже не важно, потому что, ну, в графе всегда есть способ сделать вычислениями петлю

точнее не чистый CAP но явно что-то подозрительно похожее. жаль почитать про это пока ещё негде 😃

ну да, был выбран набор ограничений исходя из стоявших перед авторами целей

не осилил mobx непонятно для меня работает

Да не было у автра цели строить асинхронный граф обработки событий. Была всего лишь цель затрекать к каким переменным обращаются компоненты реакта и вызывать перерендер этих компонентов когда переменные изменятся. Ну и позже была добавлена возможность кеширования тяжелых вычислений (геттров) над этими переменными чтобы они перезапускались в момент изменений зависимостей (которые тоже могут быть компютедами)

ну я так и сказал)

Грубо говоря mobx это всего лишь решение тормозов реакта (трекает как компоненты связаны с переменными чтобы вызвать потом перерендер только нужных компонентов).
Как без mobx вызвать обновление компонентов когда меняется состояние? Да просто храним состояние в глобальной переменной window.state = { count: 0 } а потом при изменении просто вызываем перерендер всего приложения

<div onClick={()=>{
  window.state.count++;
  actualizeDOM();
}}>
 {window.state.count}
</div>

....

const actualizeDOM = ()=>{
  ReactDOM.render(<App/>, document.body)
}

И если бы реакт не тормозил бы при диффе всего дерева приложения на каждое изменение состояния то mobx был бы и не нужен (а кеширование вычислений в компютедах нужно прям очень редко)

<div onClick={()=>{
  window.state.count++;
  actualizeDOM();
}}>
 {window.state.count}
</div>

....

const actualizeDOM = ()=>{
  ReactDOM.render(<App/>, document.body)
}

заменив mobx на "реактивность" смысл написанного не изменится)