Обновить
4K+
4

Архитектор ПО

10
Рейтинг
3
Подписчики
Отправить сообщение

Спасибо за отзыв! Буду рад обратной связи по опыту использования.

Добавил себе 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.

Еще раз благодарю за анализ!

Благодарю за комментарий! Буду ждать обратную связь.

удалось решить проблему?
Спасибо за метод.
Так тут можно как раз рисовать дугу эллипса средствами параметрического уравнения.
И правда. Написал функцию рисования эллипса через параметрическое уравнение. Наложил. Разница заметна. jsfiddle.net/Smoren/ztpy8pag

function drawEllipseParam(ctx, coords, sizes, angle, segments) {
    ctx.save();
    ctx.translate(coords[0], coords[1]);
    ctx.rotate(angle);
    ctx.beginPath();
    var x, y, firstTime=true;
    var dt = 1/segments;
    
    for(var t=0; t<2*Math.PI; t+=dt) {
        x = sizes[0]*Math.cos(t);
        y = sizes[1]*Math.sin(t);
        if(firstTime) {
            firstTime = false;
            ctx.moveTo(x, y);
        } else {
            ctx.lineTo(x, y);
        }
    }
    
    ctx.strokeStyle = 'blue';
    ctx.stroke();
    ctx.closePath();
    ctx.restore();
}
спасибо за вариант!
Я думал и о таком варианте решения, но решил остановиться на кривых Безье, потому что раньше с ними не работал.
спасибо за совет!
Спасибо, что тыкнул носом. Выборочное зрение — гадкий навык.

Информация

В рейтинге
810-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Фулстек разработчик, Архитектор программного обеспечения
Ведущий
От 350 000 ₽
C++
Python
NumPy
Pandas
TypeScript
Vue.js
Проектирование архитектуры приложений
Linux