в простейшем случае будет так

схема приложения без роутинга связей

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

кстати, для рисования рассмотри sprotty от eclipse

они там автоматический лэйаутинг умеют

и еще сейчас вышел наконец-то SiriusWeb

я уже всё это много раз опробовал, это всё фундаментально не то

ну по крайней мере они стрелочки ломать правильно умеют :)

стрелки ломать я сам умею норм, это даже не 1% работы

для рисования схемы достаточно чистого svg

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

роутинг стрелочек больше не проблема, реальная проблема — как выразить символами настолько абстрактные отношения как attach

Если какой-то стор создан путем вызова restore на эффекте, то ивент finally на эффекте будет вызван до или после обновления этого стора?

стрелки одностороннние, так? тогда вот тебе аттач, который описывает петлю, не являясь ни source ни target

тред про окрестности юнита для понимания характера проблем)

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

прикольно

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

const events = useEvent({
  eventA,
  eventB,
  eventC
})

а теперь юзаем сами евенты:

events.eventA();
events.eventB();
events.eventC();

Это бы упростило работу с множеством евентов и решило бы проблему именования: когда делаем useEvent(eventA) мы по идеи хотим евент с таким же именем, но оно уже занято в текущем файле, приходить переименовывать.

const events = useEvent({
  eventA,
  eventB,
  eventC
})

events.eventA();
events.eventB();
events.eventC();

А у тебя ssr?

да