We maintain a GitHub Repository, which you can star to follow version updates. We also notify of changes on Twitter.
GoJS has been rewritten in TypeScript.
A source license will include .ts source files as well as .js files.
GoJS can be compiled from the TypeScript source files. Dynamically building GoJS this way allows unused modules/code to be removed. See the new Intro page on building GoJS from TypeScript sources
GoJS can run in DOM-less environments, like Node, without any dependencies. See the new Introduction page on GoJS with Node.js.
GoJS cannot guarantee accurate Picture and TextBlock measuring in DOM-less environments,
so if you do not set desiredSize (or width and height) on TextBlocks or Pictures,
you may want to use GoJS inside of a headless browser project, like Chrome's Puppeteer.
We detail how to use GoJS with Puppeteer in the Server Side Images
Introduction page.
DOM-less environments can be used for server-side work, such as computing complex layouts. Headless environments such as Puppeteer can be used to do layout calculations or to make server-side images of Diagrams.
See the note about Diagram.viewSize below.
DraggingOptions holds properties for Part-moving operations, and DraggingInfo holds relative positions of dragged objects, for use in snapping and cancellation. The DraggingTool has an instance of the DraggingOptions class, and setting properties like DraggingTool.isGridSnapEnabled modifies this instance. If the Diagram has no DraggingTool associated with it, it falls back to the default properties of the class. You can create your own to pass to part-moving methods. Typically you do not need to create an instance of this class.
Moving parts has been reworked. Diagram.moveParts, Diagram.computeMove, and CommandHandler.computeEffectiveCollection now accept an additional argument for a DraggingOptions instance. This allows fine-grained control over programmatic moving of nodes. Typically, these options are supplied by the DraggingTool.dragOptions instance.
DraggingTool.computeMove functionality has been moved to Diagram.computeMove, and DraggingTool.computeEffectiveCollection functionality has been moved to CommandHandler.computeEffectiveCollection. These methods remain on their original class for compatibility when overriding, but the main functionality has been moved to the Diagram class for tree-shaking reasons.
"GainedFocus" and "LostFocus" DiagramEvents,
which allow functions to be called when the Diagram's canvas gains or loses focus,
without having to access any of the DOM within the Diagram.div.
callback and callbackTimeout options.
If a callback function is provided, the methods will instead return null
and image creation will wait until all Diagram Picture sources are loaded
before creating the image and invoking the callback.
samplesTS folder in the kit.
In order to shrink the size of the GoJS library we no longer define most predefined figures in the library. Instead, you can find all of their definitions in the Figures.js file. You can load this file or simply load only those figures that you want to use by copying their definitions into your code. For example, the Shapes sample loads this file.
A number of very common figures remain predefined in version 2.0. The figures that remain in 2.0 are: "Rectangle", "Square", "RoundedRectangle", "Border", "Ellipse", "Circle", "TriangleRight", "TriangleDown", "TriangleLeft", "TriangleUp", "Triangle", "Diamond", "LineH", "LineV", "BarH", "BarV", "MinusLine", "PlusLine", "XLine".
Note also that the definitions that are in the Figures.js file are not entirely the same as their definitions in version 1.*. A number of figures have been improved and some figure parameters have been added or changed meaning. To use the old predefined figures, you can load or copy from the "extensions/Figures.js" file of an earlier version of GoJS.
The GoJS List, Set, and Map constructors no longer take
type arguments and no longer do type checking in JavaScript.
However, when using TypeScript these classes are now generic and will do type checking at compile time.
In JavaScript, instead of new go.List(go.Point), write new go.List().
For compatibility, you can still provide an element type argument, but it is not used and not checked.
In TypeScript, instead of new go.List(go.Point), write new go.List<go.Point>(),
and the TypeScript compiler will enforce the List element typing.
All three constructors now take an optional Iterable or Array argument that
provides the initial elements for the new collection.
In a future major version, we may replace go.Map and go.Set with
enhanced ES6 Map and Set classes.
Map and Set collections.
This may affect data-bindings, in the uncommon case where a template binds Panel.type.
You should make sure that any data bindings are returning possible type values such as go.Panel.Horizontal.
Data binding Panel.type without using a conversion function will not work with old data,
since the property has changed type.
offsetX/offsetY of GraphObject.alignmentFocus has been reversed.
If you are using the offsetX/offsetY values in GraphObject.alignmentFocus,
this may cause your panels to be arranged differently.
You will need to flip the sign to retain compatibility.
This change is to rectify a design inconsistency with Spot Panel elements.
The offsetX/offsetY values now correctly offset the alignment focal point,
and not the Spot Panel's element itself.
The only use for this property was with the "SelectionDeleting" DiagramEvent
in order to prevent the user from deleting the selection.
Where one might have written this Diagram listener:
"SelectionDeleting": function(e) {
if (e.diagram.selection.any(function(p) { return p.data.key.indexOf("e") >= 0; })) {
e.cancel = true;
}
}
one can write the equivalent functionality with this CommandHandler.canDeleteSelection method override:
"commandHandler.canDeleteSelection": function() {
return !this.diagram.selection.any(function(p) { return p.data.key.indexOf("e") >= 0; })
&& go.CommandHandler.prototype.canDeleteSelection.call(this);
}
Overriding the method supports the updating/enablement of commands that call CommandHandler.deleteSelection.
Furthermore not having a "cancel" property on the DiagramEvent avoids any potential problems that might occur if there
are multiple listeners for the "SelectionDeleting" event.
The "SelectionDeleting" DiagramEvent remains useful,
but not for controlling whether or not the deletion should happen.
Updated the styling of buttons. Buttons are now rounded rectangles and have an effect when pressed. Some predefined buttons have increased a small amount in size: