а нужен ли он для сайтика на 8 page?

Гемора меньше в любом случае.

ну вот в vue там вроде MVVM фрейм, а что такое реахт вообще не понятно, там то же можно MVVM?

Нет, смысла нет.

а какой там паттерн проектирования?

а какой там паттерн проектирования?

а какой там паттерн проектирования?

one-way ) Да просто иммутабельный объект в котором хранится весь стейт приложения и чистые фукнции доступа

Не обязательно. MobX как бы мутабеленый подход практикует) еще react это TFRP то бишь функциональное реактивное программирование

я с Mobx не сталкивался, но мутабельный стейт хорош, когда он огромен, в противном случае с иммутабельным проще

В mobx мутабельности столько же сколько и в redux-е. Просто из-за того что в редаксе один стор а в mobx-е сторов много, то может показаться что там все мутабельно. Но на самом деле то что выглядит мутабельным, например user.firstName = "..." является установкой нового значения целого стора - user.firstNameStore.set("...") точно так же как и в redux происходит установка нового значения которое вернули редюсеры после диспатча

Советую почитать эту статью: https://hackernoon.com/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254 MobX использует граф состояний и вычисляет конечный финальный стейт только при необходимости (лениво) еще и мемиизируя его. Пока это не произошло ты именно мутируешь это дерево или скорее derivation stack.

Нет, это ты пиаришь свою библиотеку bgnx/xmob на хабре, а на медиуме как раз объяснение как работает mobX от самих разработчиков, на эту статью даже FAQ официальной документации ссылается Не вводи людей в заблуждение!

в той статье описан видимо старый и не самый эффективный алгоритм Counting the number of ready / stale messages will ensure that, for example, computed value ‘4’ will only re-evaluate after computed value ‘3’ has become stable., сейчас mobx использует более эффективный способ вызова подписчиков, советую почитать эту статью https://habrahabr.ru/post/349022 А насчет мутаций то там происходит мутирование не дерева а значений сторов - то есть например стор const AppStore = {firstName: observable("vasya"), lastName: observable("pupkin")} аналогичен двум redux-сторам const AppStore = {firstName: createStore(...), lastName.createStore(...)} и когда в mobx мы как будто мутируем user.firstName = "..." то декоратор вызовет сеттер а тот сделает user.firstName.set(...) и этот мини-стор firstName установит новое значение стора точно так же как в варианте с редаксом установится новое значение firstName стора которое вернут редюсеры после вызова user.firstName.dispatch(...). То есть вся разница в том что в redux-е используется один стор и необходимость возвращать иммутебельное значение стора вынуждает пересоздавать вложенные объекты то в mobx несмотря на точно такую же необходимость возврата иммутабельного значения стора (потому что иначе он не поймет нужно ли вызывать подписчиков) но благодаря возможности создавать отдельный стор на каждую ячейку и поле в объекте не нужны такие манипуляции с пересозданием объектов в редюсерах и mapStateToProps потому что можно просто создать отдельный стор на каждое поле в глубоком объекте состояния и компоненты будут подписываться на каждое такое поле независимо от других полей

Ты в своей библиотеке как раз таки используешь давно себя изжитый метод dirty-check, который например использовался в Angular 1.x, но в моследствии даже они от него отказались. MobX работает не так!

Ты в своей библиотеке как раз таки используешь давно себя изжитый метод dirty-check, который например использовался в Angular 1.x, но в моследствии даже они от него отказались. MobX работает не так!

еще раз повторю mobX использует структурное или обычное (shallow) сравнение, а не dirty check https://github.com/mobxjs/mobx/blob/a867e87788a3aeb5d03a0a99f8379c13edd6be25/src/api/computed.ts#L75

Так, я смотрю повторяется наш недавний спор о Canvas-е и Skia. Помнишь чем все закончилось? Я если честно не вижу смысла с тобой спорить, как то надоело уже. Просто не вводи людей в заблуждение

зачем съезжать - есть вопросы или аргументы - приводи. Никто не может знать все на свете. Вдруг я тоже ошибаюсь. Я пока пытаюсь объяснить что есть разные независимые части библиотеки - одна часть просто сравнит новое значение с текущим и как она будет делать неважно - либо строгое сравнение value !== newValue либо стуктурное shallowCompare(value, newValue) или вообще глубокое deepEqual(value, newValue) - неважно важно что после того как это сравнение произойдет нужно будет либо вызвать подписчиков (если несовпало) либо ничего не делать. А вот дальше уже есть вторая часть и сравнение этих самых алгоритмов вызова подписчиков. Первый вариант можно прямо в цикле вызвать this.subscribers.forEach(sub=>sub()) но очевидно что будут лишние перерасчеты для ромбовидных зависимостей. Дальше автор mobx-а в докладе приводит алгоритм dirty-clean который прежде чем вызвать подписчиков рекурсивно пометит их как diry а потом как clean и вызовет их в порядке сброса dirty до нуля и таким образом можно избежать лишних перерасчетов но не всех. Дальше есть еще как вриант алгоритм вызова подписчиков отсортировав их по глубине что будет эффективней но все равно будут лишние перерасчеты в некоторых ситуациях ну и есть последний правильный алгоритм который избежит всех лишних перерасчетов

зачем съезжать - есть вопросы или аргументы - приводи. Никто не может знать все на свете. Вдруг я тоже ошибаюсь. Я пока пытаюсь объяснить что есть разные независимые части библиотеки - одна часть просто сравнит новое значение с текущим и как она будет делать неважно - либо строгое сравнение value !== newValue либо стуктурное shallowCompare(value, newValue) или вообще глубокое deepEqual(value, newValue) - неважно важно что после того как это сравнение произойдет нужно будет либо вызвать подписчиков (если несовпало) либо ничего не делать. А вот дальше уже есть вторая часть и сравнение этих самых алгоритмов вызова подписчиков. Первый вариант можно прямо в цикле вызвать this.subscribers.forEach(sub=>sub()) но очевидно что будут лишние перерасчеты для ромбовидных зависимостей. Дальше автор mobx-а в докладе приводит алгоритм dirty-clean который прежде чем вызвать подписчиков рекурсивно пометит их как diry а потом как clean и вызовет их в порядке сброса dirty до нуля и таким образом можно избежать лишних перерасчетов но не всех. Дальше есть еще как вриант алгоритм вызова подписчиков отсортировав их по глубине что будет эффективней но все равно будут лишние перерасчеты в некоторых ситуациях ну и есть последний правильный алгоритм который избежит всех лишних перерасчетов

tl dr 🙂 как ты пишеш такую простыню?

Ты не читал пейпер что я скидывал недавно?

Не уверен, что такие эпитеты как "правильный" здесь стоит применять)

Ты не читал пейпер что я скидывал недавно?

он слишком академический я его так и не понял)

Ты не читал пейпер что я скидывал недавно?

tl;tr: вместо того чтобы определять статус обновления всей ветви графа, достаточно тупо выделить левый, правый, верхний и нижний узел)

tl;tr: вместо того чтобы определять статус обновления всей ветви графа, достаточно тупо выделить левый, правый, верхний и нижний узел)

интересно, осталось только понять суть алгоритма, или хотя бы на примере какую проблему он решает. Я так понял это больше применение алгоритма похожего на mobx для эффективной реализации иммутабельности? Или он относится именно к вычислениям и поддержанию дерева мемоизированных функций как в mobx?

Всем даров) помогите нубу плез

Пока рациональнее всего выглядит идея замутить что-нибудь на Mealy machine

Советую тогда глянуть вот это: https://github.com/krasimir/stent