We maintain a GitHub Repository, which you can star to follow version updates. We also notify of changes on Twitter.
For 2.0, GoJS has been rewritten in TypeScript, with improvements to stability and documentation.
All customers (with or without source code license) can take advantage of the TypeScript definitions .d.ts file,
which is much more comprehensive in 2.0.
A source license will now include TypeScript source files as well as JavaScript sources,
and examples of how to build the library into your project with Webpack or Browserify,
should you wish to. This will allow you to remove unused modules from the source code,
such as Layouts, Models, and Tools that you are not using. Note that unless you have strong minification,
you may not see size improvements over the pre-built go.js library, which is highly optimized.
The size of the `go.js` library has been slightly reduced (both uncompressed and gzipped), from 1.8 versions.
The main library has been reduced by removing many of the uncommon figures. These are now an extension. (Figures.js)
GoJS can now be run DOM-less, in Node.
We have added the ability to create your own Panels, with the new PanelLayout class. See an example here.
{ [index: string]: any; },
to allow easier manipulation of data Objects, mostly in Models and change notification.
Many methods and properties now use ObjectData instead of Object in the go.d.ts file.
The compiled JavaScript is unchanged by these better type declarations.
string type for arguments to
Diagram.addDiagramListener, Diagram.removeDiagramListener, Diagram.scroll,
and for the properties
Shape.strokeCap, Shape.strokeJoin, and TextBlock.textAlign.
JavaScript calls to these methods are unchanged by these better type declarations.
$(go.Node, . . ., { contextMenu: $<go.Adornment>("ContextMenu", . . .) }, . . ..
Also, you may find that event handlers need to have precise type declarations for the arguments. For example:
$(go.Node, . . ., { click: function(e: go.InputEvent, node: go.GraphObject) { . . .} }, . . ..
JavaScript calls to this function are unchanged by the better type declarations for GraphObject,make.
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.
Many of the minor changes were made to order to increase the modularity of the implementation. Nevertheless we have tried to maintain API compatibility with version 1.*.
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: