О людях, которые хотят меньше писать код

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

загнул так загнул) Прям в конце не хватает волшебного "Очевидно, что...."

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

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

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

оперативка зараза?

ну все effector посоны

загнул так загнул) Прям в конце не хватает волшебного "Очевидно, что...."

Очевидно, что если представить все циклы в неправильном, сломанном графе (directed a cyclic graph не имеет циклов) как отдельные вершины, то есть провести конденсацию, то такой граф во всех без исключения случаях будет корректным, после чего я применил Tarjan’s components algorithm для топологической сортировки и нахождения колец, и постулируя что все циклы достаточно выполнить один раз, свёл выполнение к прямой линии — профит Это если что я уже в проде заюзал, это вполне практическая задача

Очевидно, что если представить все циклы в неправильном, сломанном графе (directed a cyclic graph не имеет циклов) как отдельные вершины, то есть провести конденсацию, то такой граф во всех без исключения случаях будет корректным, после чего я применил Tarjan’s components algorithm для топологической сортировки и нахождения колец, и постулируя что все циклы достаточно выполнить один раз, свёл выполнение к прямой линии — профит Это если что я уже в проде заюзал, это вполне практическая задача

а мисье знает толк в математическим формализме)

Не было мыслей, что можно проще?

Были

Нельзя

Это алгоритм на пол странички

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

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

Данному алгоритму даже кнут респектовал https://en.m.wikipedia.org/wiki/Tarjan's_strongly_connected_components_algorithm

А можно описать простыми словами какая проблема решается? Не описание самого алгоритма а той проблемы взаимно зависимых вычислений (или что там решается) на простом примере с js?

Кнопкой моргать

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

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

я пришел к более простому варианту у меня глобальные экшены которые данные гоняют при надобности из одного в другой))))))

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

Редакс просто так сделан что по сути сделать кусок стейта в зависимости от другого куска - сразу превращается в боль

как скоро я себе в башку таким методом выстрелю?)

Дюжина экшнов есть?

Редакс просто так сделан что по сути сделать кусок стейта в зависимости от другого куска - сразу превращается в боль

Нет

Дюжина экшнов есть?

которые гоняют данные между редюсерами?

Ага

Просто это лишь отсрочит появление этой проблемы)

не дюжены пока нет, ну я понял о чем ты)

типа потом у меня станет овер дофига)

Если один экшон слушает несколько редьюсеров ?

Типа вот это всё образует паутину зависимостей в которой путаешься очень и очень быстро, это не редакс такой плохой, это by design

И я просто искал автоматическое решение данной фигни в общем виде

Типа вот это всё образует паутину зависимостей в которой путаешься очень и очень быстро, это не редакс такой плохой, это by design

Понял о чем ты теперь

Типа вот это всё образует паутину зависимостей в которой путаешься очень и очень быстро, это не редакс такой плохой, это by design

ну я парарельно начинаю mobx включать в проекты, там ссылками можно все это красиво провернуть вроде бы как

Это ещё одна попытка отсрочить неизбежное

Это ещё одна попытка отсрочить неизбежное

вроде не должна)

И я просто искал автоматическое решение данной фигни в общем виде

Когда на каждой второй странице начали попадаться сноски unsolved problem in computer science я реально люто отложил кирпичей; я не думал что это начнётся буквально с порога

ну еще вариант есть, просто диспатчить экшен другого редюсера

Да

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

Это ещё один вид связи

Во все той же паутине)

Это ещё один вид связи

эмм в плане вид связи? получать данные getState в редюсере?)

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

Когда на каждой второй странице начали попадаться сноски unsolved problem in computer science я реально люто отложил кирпичей; я не думал что это начнётся буквально с порога

А можно чуть понятней что конкретно решается? Ну там например нужно избежать двойного перерасчета селекторов как например здесь https://github.com/tomazy/xcell/blob/master/packages/xcell/src/cell.test.ts#L40 или проблема в другом? Хотелось бы выяснить минимальный пример на js или схематично (чтобы можно было описать простыми словами например типа вот одна переменна вот вторая, вот третья которая зависит от этих двух и вот четвертая которая зависит от первой и третьей) где будет видно что вот когда переменная меняется при вызове подписчиков подряд мы получаем двойной перерасчет или такие-то проблемы а вот этот алгоритм компонентов Таржана все эти проблемы решает. Просто мне кажется что если проблема в лишних вычислениях то вполне достаточно того алгоритма что находится в mobx без всяких алгоритмов связности компонентов на графе

Братан я уже слышал про то какой мобикс крутой, меня не устраивает его ад хок решение

Я знаю что все это вообще нафиг не сдалось в рантайме

В данный момент мое решение уже сворачивается препаком в ноль

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

Я в общем говорю, если у тебя уже по факту есть потребность организовать связь между данными, то уже особо не важно как именно её реализовывать, она все равно будет усложняться с одной и той же скоростью (моментально) Это можно разрулить аккуратно построенным апи библиотеки, которая бы структурировала всё происходящее в голове юзера Но для этого нужно исчерпывающееся доказательство того что либо не начнёт спотыкаться при неограниченном увеличении количества связей Счёт идёт на сотни небольших шагов , в которых невозможно уже разбираться вручную и поэтому нужно безотказное автоматическое решение

Я знаю что все это вообще нафиг не сдалось в рантайме

И для того чтобы это понять не нужны примеры, достаточно просто убедиться что компайл тайм решение было бы поедпочтительнее

Братан я уже слышал про то какой мобикс крутой, меня не устраивает его ад хок решение

Я не про мобикс я про его алгоритм - там очень просто решаются проблемы циклических зависимостей без всяких компонентов связаности на графе

Учитывая простоту алгоритма, вероятнее всего оно просто присутствует там неявно (для самого автора)

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

Я видел его очень просто, нет, такое решение это очень непросто и к тому же черевато

Я слишком ленивый чтобы надеяться на полумеры

Я в общем говорю, если у тебя уже по факту есть потребность организовать связь между данными, то уже особо не важно как именно её реализовывать, она все равно будет усложняться с одной и той же скоростью (моментально) Это можно разрулить аккуратно построенным апи библиотеки, которая бы структурировала всё происходящее в голове юзера Но для этого нужно исчерпывающееся доказательство того что либо не начнёт спотыкаться при неограниченном увеличении количества связей Счёт идёт на сотни небольших шагов , в которых невозможно уже разбираться вручную и поэтому нужно безотказное автоматическое решение

ну я про тоже говорил, что без связи ни куда. Усложняться да будет, а деватся куда, я не один на проекте, там если сказать не ридакс, меня сожгут к чертям на костре))))) Буду что нить придумывать в рамках ридакса что бы работать со связми, может утилс небольшой напишу или еще что ..

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

Бля

Нет, нельзя

Сорян, у меня нет другого ответа для подобной формулировки

Нет, нельзя, это очень сложно, go away

Постулируя готовое решение как прекрасное решение ты лишаешь себя выбора, не смею в этом тебе мешать

Постулируя готовое решение как прекрасное решение ты лишаешь себя выбора, не смею в этом тебе мешать

Ух заинтересовал, я просто не знаком с этим алгоритмом Таржана но я хорошо знаю как работает mobx и если они оба решают одну и тут же задачу вычисления циклических зависимостей то либо должна быть какая-то взаимосвязь и эквивалентность либо обнаружится что один из них не решает проблемы которые решаются во втором

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

Алгоритм Тарьяна делает сразу ряд вещей: разделяет граф на зацикленные кольца, всё что привело бы к infinite loop становится отдельным кольцом, сколько их будет — без разницы, алгоритм находит все без исключения сразу же Сам факт выделения колец приводит к тому что граф становится абсолютно безопасным для выполнения dag Это доказывается самим фактом определения всех strongly connected components (это называется конденсацией и на картинке гораздо более понятно чем на словах) Желтый граф — безопасен. Интерпретация его — на твой вкус, это уже без разницы , это просто шесть связанных вычислений Ну и последнее, бонусом этот алгоритм делает топологическую сортировку, то есть не просто делает граф безопасным для выполнения, но и сразу говорит в каком порядке его выполнять, все шаги, сразу же, в компайл тайм

Не то чтобы я аппелировал к авторитету, но Кнут абы что хвалить не стал)

У меня один вопрос - этот граф зависимостей статичен или может изменятся во время вычисления? Например есть селектор const fullName = ()=> firstName.length >= 10 ? firstName : firstName + ' ' + lastName (зависит от firstName и от lastName но не постоянно а по разному при различных условиях - если длина имени меньше 10 то только от firsName а если больше то уже от firstName и lastName)

ERROR: S client not available

Это два графа

Но ты конечно метко смотришь, респект)

То есть этот алгоритм учитывает что циклические зависимости не являются статическими а могут меняться во время вычисления?

Динамическое программирование оптимальнее не перебарывать играя на том же поле, а сводить к более предсказуемым кейсам Если ветка «зависит от firstName и lastName» некорректна, то она некорректна заранее при вычислении в компайл тайм

Просто в mobx это учитывается иначе можно нарваться на то что мы делаем вычисление селектора а потом оно оказывается не нужным потому что граф зависимостей уже изменился

Это можно свести к иммутабельной смене графов, как реле

Плюс алгоритм иерархичен, каждый strongly connected component образует изолированную замкнутую область, которую можно рассчитывать отдельно

То есть подход такой: разбить все выполнение на участки (вернее, просто найти эти участки), каждый участок рассчитать на предмет опасных и некорректных кейсов отдельно и заранее показать ошибку в случае проблем (в идеале, по желанию, проблемный код тупо не компилируется)

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

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

Со всеми развилками

Это связано с тем, что нельзя одновременно видеть и положение и направление движения (как в квантовой механике), то бишь, если юзер делает set и ждёт таймер ровно через секунду то это вынуждает код менять все свои планы на лету и переламывать ход выполнения в угоду Если же это всё описано как «а вот при этом событии мы запишем стейт (но не сами) и через секунду дёрнем триггер» то невозможно обнаружить точный момент когда это всё происходит, а значит, подстраиваться под юзера на лету больше не требуется — профит.

Просто в mobx это учитывается иначе можно нарваться на то что мы делаем вычисление селектора а потом оно оказывается не нужным потому что граф зависимостей уже изменился

tl tr: В мобикс можно нарваться и поэтому это вынуждены учитывать. Всегда значительно выгоднее сделать некорректные состояния unrepresentable

tl tr: В мобикс можно нарваться и поэтому это вынуждены учитывать. Всегда значительно выгоднее сделать некорректные состояния unrepresentable

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

Да, я про это и пишу

И это решение этой проблемы

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

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

Кстати, весь опыт жс учит тому, что мемоизация не нужна и значительно чаще есть смысл довериться V8

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

У тебя режим уплыл так, что сейчас день или тебе просто не спится ?

Я в час проснулся

Позавтракал уже))

И это решение этой проблемы

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

Это нормально, это частое решение нерешаемых, казалось бы, проблем

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

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

Могу сформулировать что зависимости функции корректны тогда и только тогда, когда их возможно представить в виде adt — суммы типов из функциональных языков

Я считаю стремление иметь настоящее недетерминированное выполнение просто не нужным

При недетерминированном выполнении у тебя появляются недетерминируемые проблемы, just as planned

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

То что вариантов больше одного не означает что их обязательно бесконечно много

Могу сформулировать что зависимости функции корректны тогда и только тогда, когда их возможно представить в виде adt — суммы типов из функциональных языков

эта формулировка еще непонятней) Окей, скажи это где, в эффекторе находится тот самый алгоритм? Попробую тогда разобраться и продебажить эффектор что-ли, самому интересно)