Our experience creating a flowchart editor for a web application

To any company that deals with tools for developers, sooner or later a delegation of clients comes. With the words "there are no programmers, the tasks are simple, you need a visual editor." We have been dealing with the automation of telephone and video calls for many years, we are well aware of whom the robot is calling and why, we love VueJS, it doesn’t hurt our heads. Why not do it? Under the cut is the backstage and the technical side of what marketing has beautifully called “Smartcalls”.

Signs of a good flowchart editor

What does the visual editor look like from the user's point of view? This is a palette of elements, the ability to drag them onto the canvas and connect them with arrows. In general, there is nothing complicated and there are dozens of libraries in the front-end world that solve a similar problem. Difficulties arise when several elements accumulate on the canvas, and the user begins to move them, freeing up space. The key point is what happens to the arrows. The simplest scenario from real life, “call the customer, offer a discount, listen to what he says”, as it hints to us that there will be a lot of squares and arrows :

And we want that when the user begins to move these squares, the result should be at least readable, and not "an explosion of arrows in a pasta factory." Like this, for example:

First experiments

There are many ready-made and free libraries for drawing flowcharts in the frontend. Having carefully examined who uses what, we settled on a project with the beautiful name " Storm " and its part " React Diagrams ". The thing is popular, it is developing dynamically, everything looks beautiful "out of the box" and works smartly. React, again, is a good friend of VueJS.

Everything was fine until we collected the first demo and started dragging the boxes connected by arrows. It turned out that Storm could not automatically and beautifully go around the squares with arrows. Not that it cannot at all - you can manually set the “bending points” and calculate everything yourself. And if you do not count, then the lines will go through the squares “through” and the pattern will be similar to the scribbles of a two-year-old child. Not the best interface solution for the thing with which people from the business will collect robots to confirm orders, delivery, surveys and invitations to interviews.

Choosing JointJS

Realizing what we needed, we once again reviewed the list of candidates and chose the next victim of inhuman experiments: the JointJS library , which is used by Amazon and other large companies. Why didn’t we immediately choose her? jQuery, Backbone and SVG. Not the most modern technology stack with a number of inherent flaws.

But with automatic routing of connections, they are doing well. Of course, if you throw a lot of elements on the canvas and start arranging them creatively, sometimes automation can’t cope (you can try on smartcalls.io ), but for most practical situations the lines are adequately rearranged, they go around the elements and you can easily look around the resulting circuit and understand what kind of automation will happen when you click on the call button.

Strengths and weaknesses of the library

Let's start with jQuery. Like most solutions based on this thing, JointJS loves the global scope and expects a number of objects in it. To build a modern VueJS application with JointJS, we had to dig into Webpack and properly organize the assembly. If someone in your team is good at Webpack (or equivalents), then this will not be a problem for you. But we did not find a ready-made instruction for “working out of the box” - perhaps we will write a small tutorial on Habré if there is interest.

It’s not easy to add new blocks to JointJS - it’s a fee for simplicity and wide possibilities for customizing the appearance of existing blocks. But we, with our five-year experience in telephone automation, are for sureThey knew what entities our customers were used to working with. They turn for consultations, show us the schemes made in various editors, sometimes we help them create scripts. And in these schemes there is much in common that we wanted to reflect in our visual editor: working with conditions, variables, external services, voice menus. To make the elements exactly the way we wanted to see them, I had to get pretty deep into the guts of JointJS.

Well, in general, the library is not simple. It will take time to figure out how everything works, what settings and how to change, what is responsible for what. On the other hand, a visual editor is not the easiest thing, and investing time in a library that will solve complex problems for us is a good idea.

The configured JointJS does its job very well: fast SVG engine, automatic routing of connections, compatibility with a large number of browsers. At the same time, the difficulties of adding your own elements are more than offset by the broadest possibilities for customizing existing ones. You can customize everything: color, shape, behavior in different situations. The result is interfaces that are convenient and pleasant to work with.