С чего все началось?
Я фронтенд разработчик, но стремлюсь к развитию, решил написать fullstack приложение и
Так вот, начал планировать бэкенд, выбрал MongoDB для хранения данных, и был готов планировать структуру и связи полей.
Но столкнулся с отсутствием простого и достаточно функционального редактора схем без излишеств для NoSQL баз данных.
— Нет? Значит сделаю делов то, найти библиотеку и накидать интерфейс!
Fullstack идея была отодвинута на задний план и я начал проработку простейшего редактора схем БД.
— Наивный… – но это я понял немного позднее.
Поиски
Во первых библиотеки такого рода в основном платные и требуют за них очень немало!
Во вторых те что бесплатные не блещут функционалом или полны багов!
В третьих не будет ибо нашел MxGraph. Он практически не упоминается на просторах интернета, хотя на нем написан прекрасный сервис draw.io да и сам по себе это весьма удобный инструмент для визуализации и редактирования данных.
Представление
О Vue.js думаю слышали все, но на всякий случай — это JavaScript — фреймворк для создания пользовательских интерфейсов в реактивном стиле.
MxGraph – это библиотека для визуализации и редактирования различных процессов, workflow и BPM, визуализации базы данных, отображение сетей и телекоммуникаций, картографических приложений и GIS, диаграмм UML, электронных схем, СБИС, САПР, финансовых и социальных сетей, организационных схем и многого другого.
Совместимость
MxGraph достаточно старый(но не устаревшый) инструмент поэтому простой npm install в Vue проект тут не даст нам полной совместимости. Поэтому тут пришлось перекапывать сеть и открывать производство велосипедов.
Выстраданные Найденные решения
Импорт и встраивание в компонент Vue выглядит таким образом:
<script>
import mxgraph from 'mxgraph';
// если планируется использовать встроенные интерфейсы то нужно указать пути к ресурсам
const graphConfig = {
mxBasePath: '/mx/', //the path in mxClient.basePath.
mxImageBasePath: '/mx/images', // the path in mxClient.imageBasePath.
mxLanguage: 'en', // the language for resources in mxClient.language.
mxDefaultLanguage: 'en', // the default language in mxClient.defaultLanguage.
mxLoadResources: false, // if any resources should be loaded. Default is true.
mxLoadStylesheets: false, // if any stylesheets should be loaded. Default is true
};
const {
mxClient, mxUtils, mxEvent, mxEditor, mxRectangle, mxGraph, mxGeometry, mxCell,
mxImage, mxDivResizer, mxObjectCodec, mxCodecRegistry, mxConnectionHandler
} = mxgraph(graphConfig);
window.mxClient = mxClient;
window.mxUtils = mxUtils;
window.mxRectangle = mxRectangle;
window.mxGraph = mxGraph;
window.mxEvent = mxEvent;
window.mxGeometry = mxGeometry;
window.mxCell = mxCell;
window.mxImage = mxImage;
window.mxEditor = mxEditor;
window.mxDivResizer = mxDivResizer;
window.mxObjectCodec = mxObjectCodec;
window.mxCodecRegistry = mxCodecRegistry;
window.mxConnectionHandler = mxConnectionHandler;
var editor;
// CustomUserObject
window.CustomUserObject = function (name, type) {
this.name = name || 'New Name';
this.type = type || 'New Type';
this.clone = function () {
return mxUtils.clone(this);
};
};
export default {
// vue logic
}
</script>
Зачем создал переменные, а потом еще и в window их прописал?!
Дело в том что webpack при сборке переименовывает переменные и mxgraph в последствии не может их найти. Поэтому специально для mxgraph я вынес их в глобальный объект.
Также не забудьте про конфигурацию – особенно при использовании встроенных интерфейсов mxEditor, иначе возникнут проблемы с контентом библиотеки.
А переменную editor зачем вынес из vue?!
Во время работы у нас не всегда будет возможность обратиться к переменной vue из-за контекста методов mxgraph. А вынос в глобальные переменные серьезно сэкономит время и пару горстей нервов.
Кастомные объекты данных зачем опять в window?!
Для создания новых объектов данных в mxgraph используются прототипы. Их тоже нужно записывать в window – иначе возникнут проблемы со встроенным импортом\экспортом схем.
Дальше разработка пошла легче и проблем с доступом к объектам я больше не встретил.
Я не считаю такой подход идеальным, и буду рад если кто то предложит альтернативу такому решению совместимости.
И что получилось?
Небольшое приложение для моделинга схем баз данных: nosqldbm.ru
Которое помогает мне, визуализировать примерную схему БД будущих проектов.
Спасибо что прочитали мою первую публикацию, надеюсь вам было интересно.
Полный пример на git
Репозиторий
Подборка материалов по MxGraph
Репозиторий
Небольшое руководство
API Docs
Примеры
Комментарии (25)
vanxant
01.11.2019 10:45Не, вынос в глобальную область это уж слишком костыльно. Надоевшему и охамевшему заказчику, пока никто не видит, такое ещё можно вкрячить, но выкладывать в паблик — буэ.
Покрутите вебпак (точнее даже vue.config.js/babel.config.js), а ещё лучше выкиньте его на помойку истории и переходите на парсель.
KraisLi Автор
01.11.2019 10:58Полностью согласен. Но не получалось самостоятельно настроить сборку, а подсказать некому. Поэтому просидев вечер над сборщиком просто забил и вынес в глобл.
Будет свободное время попробую перевести проект на сборку с parcel, спасибо за совет.
impwx
01.11.2019 18:58Парсел удобен, но у него куча косяков и багов, которые никто годами не чинит
domix32
01.11.2019 20:55Можно подумать у webpack нет многолетних багов и косяков.
justboris
01.11.2019 21:50Может и есть, но там много вариантов конфигурации и обычно через разное колдунство проблема решается. С parcel нужно упрашивать автора чтобы он поменял захардкоженное поведение
domix32
01.11.2019 22:27Через колдунство можно даже CMAKE настроить, я думаю. Тут же сокращается время ожидания сборки + поддержка нескольких языков/DSL вместо "захардкоженных" у webpack.
justboris
02.11.2019 10:44А точно не наоборот? Это у parcel список поддерживаемых форматов ограничен, а в webpack с помощью лоадеров можно добавить любой формат
Mingun
01.11.2019 11:50И как сам mxGraph? Много багов нашли? Беглый взгляд на ее код дает удручающую картину. Да и API какой-то стремный. К слову, хорошо продуманный API у gojs.net, но она денег стоит
KraisLi Автор
01.11.2019 12:05Не совсем удобен, но я привык быстро. Самое неудобное что контекст Vue и контекст prototype MxGraph полностью независимы друг от друга и постоянно требуется следить с каким контекстом работаешь.
Gojs — кратко: увидел — обрадовался — посмотрел на цену — пошел дальше :)
stgunholy
01.11.2019 17:01+2Делали редатор воркфлоу во vue.js приложении… Начали со joint.js… но туда надо тащить backbone и выглядит оно фигово совсем.потом попробывали jsplumbo на нем и остановились… MXGraph своей монструозностью отпугнул как раз. Потому что воркфлоу у нас на однрй вьюшке, а раде нее вот такое городить и еще кучу статичных файлов докладывать показалось через-чур.
KraisLi Автор
01.11.2019 17:26Да уж, встраивать этого монстра внутрь, например своего рабочего проекта я точно еще не готов. Только как основной элемент приложения.
stgunholy
01.11.2019 17:37Вот также после вечера шаманства решили :) JSPlumbo не идеал — но он хорошо встраивается как раз, и на мобилках работает
Kiel
01.11.2019 19:26Предлагаю убрать сетку на заднем фоне ))
KraisLi Автор
01.11.2019 19:43Чем обосновано такое желание?
Kiel
02.11.2019 00:29Клетка напоминает мне о школе, а я больше
в тюрьму не сядув школу не вернусь!)
Клетка не двигается, что дезориентирует
Является дополнительным отвлекающим средством, а зачем отвлекать пользователя на то что ему не нужно (kiss patterns)
Основной посыл: она бесполезна, не помогает и только мешает.
А вообще странный вопрос про желание, я же просто предложил убрать сетку )KraisLi Автор
02.11.2019 02:13Услышал, прикручу возможность отключения.
Эх, а вот про школу ты еще вспомнишь… Лет эдак через 5 с теплом и улыбкой
AndreyRaih
02.11.2019 02:13Доброго времени суток) А не пробовали реализовать через написание vue плагина? Возможно это было бы полезно — https://ru.vuejs.org/v2/guide/plugins.html
KraisLi Автор
02.11.2019 02:16Если сильно заморочится плагин или обертку написать можно, но не уверен что это будет полезно, ибо mxGraphрут когда нужен дикий кастом библиотеки, стандартизация методов через плагин тут только мешать будет.
AndreyRaih
02.11.2019 11:51Да, понимаю. Это скорее как альтернатива использованию window, не более того)
zivgta
02.11.2019 20:54Пытаюсь понять в чем принципиальное отличие от их готового примера, который еще и sql в конце может вернуть jgraph.github.io/mxgraph/javascript/examples/schema.html
(кроме прокладки связей между отдельными полями, а не целой таблицей)KraisLi Автор
02.11.2019 22:25Принципы построения схем вообщем то у всех редакторов одинаковы. В статье описан процесс использования в среде Vue.js.
Что касается моего варианта исполнения редактора, отличий немало(особенно под капотом) хотя и очень похожи.
Например попробуйте сделать прототип БД со смартфона в обоих вариантах и заметите разницу)
Anton_Zh
А в MongoDB схема данных появилась?
KraisLi Автор
Схем нет, но визуализация примерной схемы полей и их связей очень упрощает разработку
Anton_Zh
А UML-редакторы для этой цели не рассматривали?
KraisLi Автор
Различные варианты рассматривал, но в большинстве у них много лишнего и порой нет нужного. Тоесть куча различных элементов которые отвлекают и ненужны в моем случае, и не всегда имеется простейший показ в JSON, и приходится составленную схему прогонять через еще какой то сервис для получения валидной JSON структуры — это не удобно. Чего то подходящего конкрутно мне я к сожалению не нашел. Да и преобрести опыт в этой области было интересно.