Информация
- В рейтинге
- 810-й
- Откуда
- Москва, Москва и Московская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Фулстек разработчик, Архитектор программного обеспечения
Ведущий
От 350 000 ₽
C++
Python
NumPy
Pandas
TypeScript
Vue.js
Проектирование архитектуры приложений
Linux
Спасибо за отзыв! Буду рад обратной связи по опыту использования.
Есть за что :) Найденный Вами баг исправлен в релизе:
https://github.com/Smoren/transferum-ts/releases/tag/v1.4.0
Добавил себе issue с описанием найденной Вам проблемы, упомянул Вас. Еще раз спасибо!
https://github.com/Smoren/transferum-ts/issues/7
Благодарю за отзыв! Буду рад, если потом поделитесь опытом использования и укажете на сложности и недостатки, с которыми столкнулись.
Спасибо огромное за столь детальный сравнительный обзор! Получить в комментарии подробный аудит кодовой базы — это огромная ценность и редкое удовольствие для опенсорс-разработчика.
Ранее я не слышал о проекте $mol, поэтому сразу оговорюсь, что сейчас, после короткого изучения его основных концепций, могу не понимать всей глубины идеи, равно как и не видеть подводных камней, которые она могла за собой принести.
На данный момент могу сказать, что философия этого фреймворка выглядит необычно и весьма элегантно, но слишком радикальные отличия от общепринятых концепций разработки делают ее сложно воспринимаемой для свежего взгляда. Но это в целом скорее повод для меня почитать про него побольше.
Вы абсолютно правы в корневом разделении наших подходов: Explicit Dataflow против Transparent FRP (Pull-реактивности).
Пересчет графа “на лету” в теле методов в $mol_wire — это красивое рантайм-решение для управления состояниями. Но Transferum создавался для решения немного другого класса задач, где явный контроль над топологией важнее автоматизации. Фокус Transferum — это жесткие, изолированные конвейеры обработки данных, где разработчику нужно четко видеть каждый узел и ребро графа и контролировать потоки.
Из этой развилки вытекают сильные стороны Transferum, которые при автоматическом Pull-подходе получить трудно: максимально строгая compile-time типизация и предсказуемый backpressure.
Что касается проблемы глитчей — вы абсолютно правы, в текущей реализации используется синхронный DFS-обход. В сложных UI-графах это могло бы стать проблемой, но в рамках наших кейсов маршрутизации потоков данных эта специфика полностью нивелируется явным flow-control (гейтами и бриджами).
И отдельное спасибо за находку в AsyncConvertTransfer._process! Вы правы: если тяжелый первый запрос завершится позже легкого второго, он перезапишет _state.value устаревшими данными. Это реальное пограничное состояние, которое до этого момента не всплывало, так как в критичных местах мы использовали последовательную обработку (maxConcurrency: 1). Это надо будет, как минимум, задокументировать, а в идеале — подумать про Sequence guard.
Еще раз благодарю за анализ!
Благодарю за комментарий! Буду ждать обратную связь.