кстати, а какую задачу должен выполнять встроенный вариант? 🤔

репл состоит из нескольких практически автономных частей

— logger (визуализация всех жс сущностей в панели console)
— code editor (взаимодействие с codemirror, outline юнитов, маппинг loc из рантайма на позиции в коде)
— code compilator (много бабеля, логика по асинхронной подгрузке билдов эффектора для рантайма)
— realm runtime (скрупулёзная изоляция кода между запусками)
— stacktrace parser (используется при возникновении ошибок в рантайме, инициализируется асинхронно после первой ошибки, потому что сорсмапы жирные как паровоз)
— провайдер настроек
— авторизация
— typechecker/type hover при использовании flow
— ui/layout

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

что лучше итератор или рекурсивный вызов с next при обходе узлов?

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

а откуда рекурсия 😳😳

рекурсивный вызов если его не развернуть упадёт после первых 10k элементов)

а, ну при разворачивании такого механизма у тебя появится очередь) просто часто достаточно неявной

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

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

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

ещё и этот next отвратительный в 1000 местах

я тут только на днях вворачивал breadth first логику в depth first задачу) бонусом всё выполнение стало плоским вместо вложенного


https://github.com/zerobias/effector/commit/9013dfc35399ea80c1164f2fc52e9fefc54f6b05#diff-cca82c8bb3c550b08c87dc1fae7c2d26R624

ну типы придётся затачивать под ограничения задачи, это да

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

@ZeroBias такой вопрос. Сейчас при combine, если поменялся один из сторов, все пересоздаются?

обновляется только результат

апдейт комбайна работает так

newResult = {...oldResult}
newResult[changedField] = changedValue

кроме этих действий не выполняется ничего