How did it all start?
I am a front-end developer, but striving for development, I decided to write a fullstack application and
So, I started planning the backend, chose MongoDB for data storage, and was ready to plan the structure and field relationships.
But faced with the lack of a simple and sufficiently functional schema editor with no frills for NoSQL databases.
- Not? So I’ll do business, find a library and populate the interface!
Fullstack idea was pushed into the background and I began to work on the simplest editor of database schemas.
- Naive ... - but I realized this a little later.
Search
Firstly, libraries of this kind are mostly paid and require a lot of them!
Secondly, those that are free do not shine with functionality or are full of bugs!
In the third will not be for found MxGraph. It is practically not mentioned on the Internet, although the excellent draw.io service is written on it and in itself it is a very convenient tool for visualizing and editing data.
Representation
I think everyone has heard of Vue.js , but just in case - this is JavaScript - a framework for creating reactive-style user interfaces.
MxGraph is a library for visualizing and editing various processes, workflow and BPM, database visualization, mapping networks and telecommunications, mapping applications and GIS, UML diagrams, electronic circuits, VLSI, CAD, financial and social networks, organizational charts and much more.
Compatibility
MxGraph is a fairly old (but not obsolete) tool, so a simple npm install in a Vue project here will not give us full compatibility. Therefore, we had to dig up the network and open the production of bicycles.
Suffered Solutions Found
Importing and embedding in a Vue component looks like this:
<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>
Why did you create the variables, and then also register them in the window ?!
The fact is that webpack renames the variables during assembly and mxgraph subsequently cannot find them. Therefore, especially for mxgraph, I put them into a global object.
Also do not forget about the configuration - especially when using the built-in mxEditor interfaces, otherwise there will be problems with the library content.
And why did the editor variable get out of vue ?!
During operation, we will not always be able to access the vue variable due to the context of the mxgraph methods. And taking them into global variables will seriously save time and a couple of handfuls of nerves.
Custom data objects why again in window ?!
Mxgraph uses prototypes to create new data objects. They also need to be written to the window - otherwise there will be problems with the built-in import / export of schemes.
Further development went easier and I no longer encountered problems with access to objects.
I do not think this approach is ideal, and I will be glad if someone offers an alternative to this compatibility solution.
And what happened?
A small application for modeling database schemas: nosqldbm.ru
Which helps me to visualize a sample database schema for future projects.
Thank you for reading my first publication, I hope you were interested.
Full git example
Repository
MxGraph Selection
Repository
Small guide
API Docs
Examples