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

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

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

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

Начну с того, что всё-таки положил в npm и в начале вкратце. Пакет назвал sprut-gear-chain(с неймингом возможно беда, надо было длиннее). Инструмент представляет из себя стейт-менеджер, работает на геттерах-сеттерах, да, как MobX, отдаёт прокси если пришлось отдавать объект, а не стор. Под капотом предусмотрена работа с методами массива для реакции на мутирование массива. Наиболее интересной идеей мне кажется работа с Computed-полями, включающая асинхронную работу и возврат специального значения Waiting, которое является символом, настройка тайминг-функций, которые участвуют в пайплайне обработки изменений при батчинге. Инициализация сейчас не самая красивая, требует переработки или просто выпиливания устаревших и не красивых вещей.

Документация в npm не поясняет подкапотные вещи, но должна описывать все методы работы.

Затаскивал это как стейтменеджер из коробки в сборку движка на базе VDOM, сам движок, ядро, максимально тупое, является базой для этой сборки. Компоненты в нём по сути сами по себе являлись стором засчёт sprut-gear-chain, это и являлось их локальным стейтом, который сразу следит за внешними сторами, так как являются продуктами одного стейтменеджера.

Сам движок никуда не выкладывал, без типизации мне было стрёмно показывать и выкладывать. Но перед косметикой и типами планировал на базе того же sprut-gear-chain и дополнительных обёртках на нём же создать механизм автоподписок, который обходил бы этап перерендера компонентов и делал прямые изменения в DOM. Но это всё с сохранением возможности работать через перерендер и сравнение деревьев, в рантайме, без компиляции шаблонов.

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

Сам sprut-gear-chain возможно буду портировать на Dart и Flutter, хоть там уже и есть похожие инструменты. Но архитектура там точно будет иной, напрямую это не переносимо.

Ну и да, над типизацией надо работать в sprut-gear-chain.