Comments 40
Интереснее всего как вы сделали бэкенд для этой штуки и на каких объемах событий\клиентов это все работает?
Зашел: почитать об особенностях реализации редактора и автороутинга.
Увидел:
Взяли библиотеку. Там автороутинг плохо работал.
Взяли вторую библиотеку. О, норм.
Увидел:
Взяли библиотеку. Там автороутинг плохо работал.
Взяли вторую библиотеку. О, норм.
Не «плохо работал», а «нужно указывать промежуточные точки вручную». Это же достаточная степень детализации? Что еще интересует? Я gif'ки специально записал, чтобы роутинг показать :)
От статьи на хабре с таким названием я жду одного из 2х:
После прочтения Вашей статьи я понял:
А вот вопросы, которые у меня остались после прочтения статьи:
- Описания «внутрянки» Вашего решения. Алгоритмов, диаграмм с кусками кода и т.д.
После прочтения такой статьи я немножко выросту как программист;
- Сравнения готовых решений.
После прочтения такой статьи у меня в голове останутся имена 2-3 готовых решений и я буду понимать: если мне понадобится реализовать такой редактор, то начать нужно с… (лезу в Вашу статью, нахожу сравнительную таблицу и по моим критериям нахожу подходящее для меня решение).
После прочтения Вашей статьи я понял:
- Во фронтенде сейчас много готовых и бесплатных библиотек для рисования блок-схем.
- Вы проработали какое-то количество из готовых библиотек.
- Среди этих библиотек Вам встретилось две библиотеки с именами JointJS и STORM.
- Вы используете одну из них, хотя эта библиотека сложная и несовременная, но рисует связи чуть лучше другой.
А вот вопросы, которые у меня остались после прочтения статьи:
- Сколько же Вы все-таки библиотек проработали?
- Чем Вас не устроили другие библиотеки?
- Почему выбор пал на платный продукт?
- Почему не STORM + допилить алгоритм трассировки?
- ...
Есть еще gojs
UFO just landed and posted this here
Вы ваш редактор делали с какой-то целью для какого-то сервиса? А где можно потыкать в готовый результат?
Мы его делали для нашего сервиса smartcalls.io — фидбек приветствуется!
Ожидал увидеть, как реализовали такую библиотеку, а не взяли готовую. В итоге опыта я не обнаружил, слишком уж желтушным оказался заголовок.
А mxgraph не пробовали?
Странно, есть же Smart routing
Надо было во vueJs дать возможность пользователям создавать/рисовать воркфлоу свои… Также использовал jointjs (бесплатную версию)… Вебпак не трогал, единственная засада была в подключении библиотечек которые для jontjs авто-лейаут делают и зум диаграм по-простому сделать
Использую визуальный редактор Node-RED для целей домашней автоматизации. Очень доволен.
Я бы на вашем месте придумал бы как его использовать для вашей системы, чем разрабатывать свой.
чем jsPlumb не устроил?
подобное реализовывал на нём ещё год назад. всё отлично работает.
подобное реализовывал на нём ещё год назад. всё отлично работает.
А вот его мы просто не заметили. И как оно, где-нибудь в production используется? Как впечатления?
15 лет назад я видел похожую разработку на Visual Basic, это было голосовое меню для банка. Тогда всё уткнулось в:
— невозможность уместить на экране и в голове больше десяти квадратиков (т.е. не-программист всё равно не может справиться с задачей реального размера);
— отсутствие повторно используемых кусков;
— невозможность отладки;
— невозможность отследить историю изменений по системе контроля версий.
В общем, с тех пор у меня скепсис по поводу графических средств программирования :)
— невозможность уместить на экране и в голове больше десяти квадратиков (т.е. не-программист всё равно не может справиться с задачей реального размера);
— отсутствие повторно используемых кусков;
— невозможность отладки;
— невозможность отследить историю изменений по системе контроля версий.
В общем, с тех пор у меня скепсис по поводу графических средств программирования :)
Рассматривался ли Blockly?
Да, но для менеджеров квадратики со стрелочками понятнее, чем ТАКОЕ. Blockly это все же промежуточный вариант между квадратиками и кодом. Нам хотелось именно квадратиков. Потому что для разработчиков у нас есть Voximplant с JavaScript наперевес, где с голосовыми и видеозвонками можно сделать вообще всё.
Без кода это тут никому кроме вас самих не нужно.
Настроенная JointJS очень хорошо выполняет свою работу: быстрый движок SVG
К сожалению, SVG достаточно быстро ложится на лопатки при увеличении объёма информации, подлежащей отображению. Например, Draw2D неприемлемо тупит уже на 300 примитивах, а SVG.js — на 800. Под словом «неприемлемо» подразумевается 10 сек и более (на конкретных, далеко не самых дохлых компьютерах). В нашей компании требовалось отображать сразу по несколько тысяч примитивов, в виду чего пришлось отказаться от SVG в пользу растровой графики.
Проблема SVG в том, что скорость обработки данных при увеличении их объёма изменяется далеко не линейно: тынц.
В статье пишут «Performance is better with smaller number of objects (<10k), a larger surface, or both». Возможно это вопрос к Draw2D, а не к SVG?
Я ведь выше ссылку дал, в которой Microsoft демонстрирует наглядные графики, не привязанные к конкретному движку. Draw2D конечно же вносит свою лепту, причём не самую лучшую, но проблема не только в нём. SVG.JS существенно быстрее, но и он не устроил. Используемый вами JointJS я не проверял, но подозреваю, что и он не окажется «серебрянной пулей».
Да, но по факту скорость перестала нас устраивать на количестве даже меньшим чем 1k.
Вы тестировали редактор на большом объёме данных (например, 3-5 тыс. примитивов)? Если да, то каково было количество примитивов и какова скорость отображения?
В статье пишут «Performance is better with smaller number of objects (<10k), a larger surface, or both».
Да, но по факту скорость перестала нас устраивать на количестве даже меньшим чем 1k.
Вы тестировали редактор на большом объёме данных (например, 3-5 тыс. примитивов)? Если да, то каково было количество примитивов и какова скорость отображения?
в виду чего пришлось отказаться от SVG в пользу растровой графики.
Какая-то сторонняя библиотека или своя разработка?
Sign up to leave a comment.
Наш опыт создания редактора блок-схем для веб приложения