В свободное время переписывал sprut-gear-chain - стейтменеджер на геттер-сеттерах с графом зависимостей, работающий на Proxy при чтении сырых объектов в полях, переводил на typescript. Дело затянулось.

И тут решил я писать мок-сервер для апишки, начал просто в лоб, чисто для приложения. Придумал себе приколюху с траснпортом на вебсокетах, чтобы был клиент и на нём запросы в виде вопросов обрабатывались руками кнопочками или правкой JSON запроса-ответа.

Решил писать да посмотреть как там что работает на нативных модулях в браузере, через сервер работает через static, всё нормально. И начал набрасывать инструментов на скорую руку, чтобы удобно было писать. Фабрики для дом, обработчики, запись в сырые объекты, всё на событиях.

Пришёл короче я к тому, что написал универсальные фабрики, можно было бы для jsx использовать, фрагменты, кастомки для атрибутов, событий. И понадобился стейт...ну node_modules нету, тянуть в папку лень, короче начал писать стейтменеджер. Также на графах, но по интерфейсу похож на сигналы, работает нормально на примитивах, по сути реализует то, что хотел добавить в sprut-gear-chain не используя большой глобальный стор.

И пара-тройка дней превратились в аттракцион.

В итоге всё превратилось в два очередных инструмента с нуля - один стейт менеджер как сигналы, изменения в объектах валидируются по ключам, которые можно закинуть в reactive или computed, добавил событийные потоковые объекты, и сделал интерфейс в фабриках DOM для привязки к стейтменеджеру компонентов HTML-элементов. До этого писал на VDOM, многие было готово, интересные механизмы.

Но при таком подходе всё в итоге вообще с ног на голову встало. По сути такой jsx можно было бы использовать для компилируемых шаблонов, но в рантайме работает и пишется в принципе удобно и на базе js, пока что без дерево и с прямым рендерингом-созданием DOM-нод. Можно даже попытаться жизненный цикл с прямым рендерингом отслеживать и не нагружать деревьями. Всё станет ещё легче когда добавится таск фазовый менеджер.

А без VDOM, и вообще была цель делать без него, всё накладывается на работу с данными, и тут как говорил с ног на голову переворачивается. В итоге, ну как обычно вообще в таких инструментах, пришлось особенным образом работать с объектами, а не хотелось никаких Proxy и автогенераций реактивных значений в поля, всё остаётся сырым и всегда можно получить raw-значение, всё работает через методы. Но с массивом подход ещё более особенный и интересный с описанием методов по его интерфейсу.

Ввёл понятие туда ячейки элемента массива, хотел ещё в sprut-gear-chain попробовать, но как-то не надо было. В итоге диффинг не деревьев компонентов происходит, а больше диффинга по данным, элементы массива могут быть получены как реактивная ячейка и всегда ссылается на нужное значение, можно получить order и диффится это всё по id через метод получения id для массива. В итоге привязка к HTML происходит напрямую через такие объекты и сортировка будет работать через order. Не нужны find, findIndex, всегда попадаем на нужные данные забирая реактивный элемент по id или по индексу. .filter, .map, .reduce - тоже отдают реактивные обёртки и зависят друг от друга, внутри завязываются на реактивные условия и как слой выстреливают по отдельности.

А в DOM простая структура и прямые инъекции. Хотел такую штуку прицепить к VDOM своему, но руки не доходили, то есть можно было бы диффить деревья если прям надо, а можно было класть такие обёртки и напрямую обновлять, при недочётах перерендер с диффингом выручал бы всё равно.

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

Может быть солью это всё в одно, может разделю, практика покажет. Кодом если поделюсь, то позже.