Post written in cooperation with Synergy Codes.

Start with the library

GoJS is a JavaScript library that takes complex data and runs it through flexible modeling options to create visualizations that are easy to understand and put into action. You can read more about GoJS on official website or in Synergy Codes’ blog post about it.

The starting point for us is the HTML file where we import the library. We can download it directly from the website, from the npm, or we can use the CDN. The next step is to add the div element — the future location of the diagram. NOTE: We don’t create the canvas ourselves, as the library does it for us. However, the div itself may be freely refined to make it match the website. The file should look more or less like this:

Listing 1. Initial appearance of the index.html file

Code structure

The next step is to write JavaScript code that creates the diagram. We create a diagram.js file where we will put the entire logic of the application. We can create it in any convention — GoJS doesn’t dictate any specific way of building sources. For the purposes of this example, I will create an IIFE (Immediately Invoked Function Expression), which will be a named diagram with the initDiagram function available externally. By using IIFE, we will be able to hide a part of our implementation from outside access.

In the case of GoJS, our starting point for creating all objects is the go.GraphObject.make function, which calls the factory method of the selected class. It’s used so often that we should assign it to a variable with a shorter name. The generally accepted convention is to use the dollar sign for this reason. However, we need to be careful in the case of parallel use of jQuery. As the first argument, this function accepts the class whose instance is supposed to be created, while the values of individual fields of the object are accepted as subsequent arguments. It’s worth emphasizing that usually the string is given as a second argument with the value of one selected field defined in the object. Generally, it’s the field whose value is most important in the given context, such as the type of created figure.

Creating a GoJS diagram — preparation

The first thing that we want to create is the diagram itself. It is located under the go.Diagram class. The most important parameter is the id of the element it’s supposed to be placed in. This is why we call it $(go.Diagram, ‘diagram-content’).

In order to better specify the operation of the diagram object, check what fields it has in the documentation. For instance, we may assign the value go.Spot.Center to the field initialContentAlignment. This initially places the diagram’s elements at its center (by default they are in the upper left corner) of the application. Let’s put it into the initDiagram. We have to remember to call this function in the HTML file. We should get the following JS and HTML files:

Listing 2. diagram.js skeleton and creation of an empty diagram

The diagram is empty, so unfortunately we won’t see any action yet. The only thing that will show us that GoJS is working is the default action lock of clicking the right mouse button on the diagram.

Presentation of data on the diagram

The basis for the diagram is the creation of a data model for it to operate on. The model consists of two tables — nodeDataArray (data of nodes) and linkDataArray (data of edges). Nodes are the main elements of a diagram that graphically represent the objects (for example, an entity in a diagram of relations of entities). Links (edges) are the connections between nodes (directed or not), which, depending on the type of diagram, may have different meanings (such as the relation between entities in an ERD diagram).

We define the individual nodes as objects where the only required field is key, for example, a unique identifier. In addition, we can optionally define the category of objects, as well as complete them with any data which will be stored along with the node in the diagram. Edges are also defined as objects having two required fields — from and to, whose values determine which nodes are connected. Like in the case of nodes, we may also add our own additional data.

The diagram model is located under the model field of the diagram object. It’s best to define it by creating a go.GraphLinksModel object we pass the nodes and edges to. Here’s an example of what a model definition might look like:

Listing 3. Definition of the diagram model

After placing it in the initDiagram and running it, we should get a very simple diagram. It will show us the values entered in key fields connected by edges.

Figure 1. First diagram

The next step is to provide the objects with an appearance. The appearance is set by creating a go.Node object in which we subsequently create objects defining the shape (go.Shape). The simplest definition of the object’s appearance (template) would look like this:

Listing 4. The simplest definition of the object’s appearance

In this case, we will create a black circle to represent the object. Auto means the arrangement of individual shapes. In the case of Auto, each shape defined inside go.Node will be placed in layers at the center of the object. In the case of shapes, Circle was selected here, but there are many others available at: https://gojs.net/latest/samples/shapes.html. We could also set field values in the shape object — this would let us specify elements like: fill, stroke or size. In addition, we can load these values from the data model using go.Binding.

Another way to define the appearance is to create a shape using the SVG path definition. Then, we use this path as the value of the geometryString field. Here’s an example of what the template definition would look like in such a case (we’ll also set the size and color of the fill):

Listing 5. Definition of appearance using the SVG path

It’s also possible to define the appearance using images in any format (including SVG). In such cases, instead of go.Shape we have to use go.Picture. Interestingly, go.Picture can store not only images, but also other canvas-type elements. This allows us to create even more advanced visualizations.

Another way of defining the appearance of objects is to combine many different shapes into one. The advantage of this approach is that after dividing the object into several smaller ones, we can define different behaviors for each part (for example, one of the shapes may be a button on which we define a click action — in this case, only this fragment will have this event assigned). In order to create complex objects, it’s worth learning about methods for arranging shapes on an object. We’ve used Auto, which means placing everything in the middle. We also have other options, the most basic of which include: Horizontal (from left to right), Vertical (from top to bottom), Spot (placement on predetermined positions like Center, Top, Bottom, etc.). Subsequent shapes are passed as the next arguments of the function creating the Node, and they are placed in this order. For example, two rectangles, each with a different appearance and placed one on top of the other, would be defined in like this:

Listing 6. Definition of appearance consisting of several shapes

However, what if we want different types of objects? To do this, instead of assigning the appearance to nodeTemplate, we complete the map — nodeTemplateMap, where the key is the category of the object (category, which we have defined in the model), while template is the value. For the purposes of this example, let’s assume that we’ll use the definitions given above for the categories: first will be a circle, second will be SVG shape, third will be two rectangles. However, for practical reasons, we shouldn’t assign template directly to the map, but rather create the function that will return the template we will assign to which category, and then supplement the map — nodeTemplateMap using the data from it. Note that this map should be completed before we supply the diagram with the model. For example, it could look like this (some fragments of the code have been left out for clarity):

Listing 7. Suggestion for using nodeTemplateMap

Writing this should generate the following effect:

Figure 2. Diagram with three different templates for the nodes

As you can see, the diagram is beginning to take shape. In addition, it’s worth mentioning that besides the appearance of nodes, you can also determine the appearance of edges. This is defined in an analogical manner, with the difference that instead of nodeTemplate and nodeTemplateMap, we have linkTemplate and linkTemplateMap, while during the definition of a template, instead of creating a go.Node object we create a go.Link object.

You can check out the result of this tutorial here:

Want more? Check out the second part of this tutorial!

Post is also published on Synergy Codes’ blog, you can check it out here.