When a new node is dropped onto some existing node via the drop manager, the onVertexAdded callback on SurfaceDropManager now passes back information about the vertex on which the new node was dropped.
Support for the onVertexAdded callback was added to ShapeLibraryPalette
Added new panWithMetaKey option to Surface render params. With this flag you can instruct a Surface to only pan when the user is holding down the "meta" key (command key on Macs, ctrl key on Windows).
Recently a licensee who is still using version 2.x of JsPlumb wanted to upgrade their app to use Angular 16, but did not have the bandwidth to undertake an upgrade to the latest 6.x version of JsPlumb. So we pulled down 2.4.16 (the last version in the 2.x line), dusted it off to support Angular 16+, and released it as 2.50.0.
Version 2.50.0 is available to all licensees who currently have access to downloads (including new licensees). We don't recommend using 2.50.0 in preference to 6.x, but if you find yourself in a similar situation you might like to consider it.
Start a free trial
Not a user of jsPlumb but thinking of checking it out? There's a whole lot more to discover and it's a great time to get started!
The exportData method no longer writes a ports section into the output. You can use legacy-json as the type when exporting data if you still need this, but in 7.x that will be removed.
Start a free trial
Not a user of jsPlumb but thinking of checking it out? There's a whole lot more to discover and it's a great time to get started!
We've continued the work that we began in 6.10.0 on elastic groups, by adding support for nested elastic groups:
When an elastic group is inside some other elastic group and the user is dragging a child element, they are shown a preview of how all the groups will resize as a result of the drag. In the gif above we show two levels of nested groups but this works to an arbitrary depth...it's turtles all the way down.
We've added a handy new layout in 6.11.0 - the GridLayout:
A number of different alignment options are available, and you can optionally fix the number of rows or columns the grid will use. Documentation for this layout is available here.
One of our most popular starter apps is the Flowchart Builder, in which users can resize elements. This width/height information is stored in the model, and prior to 6.11.0 had to be explicitly referenced by your vertex templates:
In 6.11.0 we have introduced a useModelForSizes flag, along with a bunch of default size settings, which allows you to do away with the style shown in the template above - the Toolkit will take care of the size:
Now our template can just focus on what it needs to focus on:
<div>{{label}}</div>
When a given vertex does not have width/height information, it can be supplied either from a node/group definition in your view, or from instance defaults. If all else fails and you haven't provided a value anywhere, the Toolkit will use something it considers reasonable.
Added support for exporting a Path or Selection (including the current selection for some Toolkit instance) to an SVG/PNG/JPG.
New layout GridLayout added. This layout places elements into a grid, optionally with a fixed number of rows or columns, and with the ability to align items to the left/top/bottom/right of each cell.
Group size preview pane shown when dragging an element inside an elastic group is now displayed on ancestors of the group if they are also elastic.
Added the ability to run an ad-hoc layout on a group, via the adHocGroupLayout method on a surface.
We've had a few queries recently regarding the possibility of adding support for animated edges to the Toolkit. Like this:
We've never exposed an API to do this because it's never really occurred to us do so, given that achieving this effect is about as easy as falling off a log. There are three parts to this:
We tend to avoid polluting the Toolkit with functionality that is easily created such as this is, but if you're a licensee or evaluator of the Toolkit - or just someone with an opinion - and you've got suggestions for how we could usefully build support for this into the library, we'd definitely like to hear them.
Start a free trial
Not a user of jsPlumb but thinking of checking it out? There's a whole lot more to discover and it's a great time to get started!
6.10.0 is a significant release for the Toolkit, with a great new "elastic groups" feature, plus an overhaul of how group sizing works in general. In addition we've added a few new useful things such as the ability to enable/disable the snaplines plugin, the ability to provide a style block for an SVG export, and a bunch of other things.
Under the hood we continue to refactor the codebase to make it faster and more streamlined, as we steadily approach our 7.x release, and we've put in a couple of minor updates to ensure the Toolkit works with SvelteKit SSR.
We are pleased to announce that we now support "elastic" group sizing:
As users drag child elements around inside a group, the size of the child content is computed and a frame appears showing the user how the group's size/position will change on mouseup. If you have a minSize or maxSize set on a group the elastic resizer will take that into account (in the video below the group has a minimum size of 250px in each axis).
We've added the capability to the SVG exporter to take a styles parameter, either as a string or a JS object, which is then injected into the SVG that we export:
New flag elastic available for group rendering. An elastic group shrinks and grows as the nodes/groups inside of it are dragged around.
Added new panFilter optional function to Surface options, allowing you to control at runtime whether or not panning should be enabled.
Added support for optional minSize parameter in group definitions in the view. This is of type Size.
Added support for optional padding parameter in group definitions in the view. When autoSize is set on a group, this padding will be set around the child nodes/groups of an auto sized group. Default value is 0.
Added support for optional allowShrinkFromOrigin flag on group definitions in the view. Implicitly true when autoShrink or autoSize is true, you can set this to default if you don't want your groups to be able to shrink from the left/top edge.
When dragging a child element from a group, the parent group is assigned a CSS class of .jtk-drag-original-group. You can attach a z-index rule for this class to ensure that nodes/groups you drag from a given group will appear on top of any target group.
Added setEnabled(boolean) method to the Snaplines plugin, allowing you to enable/disable the plugin at runtime.
Added support for passing in styles to SVG exporter, for inclusion in a style element in the SVG export.
Improvements to orthogonal routing to handle vertical alignment in Hierarchy layout
Updates to the browser UI core code to fix a couple of issues that were causing the code to fail to load in SvelteKit SSR.
The behaviour of autoShrink and autoSize has been improved to support shrinking a group from its left/top edge where applicable. Previous versions of the Toolkit could only shrink a group from its right/bottom edges.
Fixed an issue with group auto size when an element is dragged into the negative axis. Previous versions of the Toolkit would size the group to fit the new content bounds but leave the dragged element hanging out of the group. In 6.10.0 the group is shifted to adjust for this.
Several improvements were made to the interaction between a Toolkit instance and its associated undo/redo manager, to ensure that not stray commands are tracked by the undo/redo manager during data load/append.
The maxSize option to group definitions is now a Size object, with a w and h property, instead of an array of [w,h].
autoSize switches on autoShrink by default now. Consider just using autoGrow if this is not what you want.
When autoSize or autoShrink is set, groups may now adjust their left/top edges to fit the content (taking into account any minSize set on a group). You can set allowShrinkFromOrigin:false to suppress this behaviour.
When dragging an element that is a child of a group, the original group is now assigned .jtk-drag-active and .jtk-drag-hover CSS classes, where in previous versions it was not. We think this provides a better experience for users but if you prefer the old behaviour you can use the fact that the .jtk-drag-original-group class is now added to the parent group to setup rules to mimic the old behaviour.
6.9.1 is a minor release but also fairly significant - we've made a few key changes in the React integration so that it fully supports being used in NextJS applications:
Updates to React integration to better support NextJS dynamic unload/reload
Updated the wheel listener to check for existence of document before testing for available event (SSR fix for NextJS)
In conjunction, we've pushed NextJS versions of three of our most popular starter apps:
Support for generating edge routing information was added to the Hierarchy layout.
New plugin edgeRouting added. This plugin can ingest the edge routing information generated by a Hierarchy layout and adjust the routes of the edges in the UI, with support for separated orthogonal, bus orthogonal and direct line modes.
Support for the number input type was added to Dialogs
Support for the number input type was added to Inspectors
A fix was added to the Orthogonal connector's geometry import routine to catch an unexpected formatting error in the geometry.
We've made some internal updates to reduce the number of classes created by connectors and connections, instead using more plain old javascript objects.
The Community ingest code has been removed. The Community and Toolkit editions in fact diverged several versions back and this code was likely not working in many scenarios. No Toolkit licensees use(d) this code.
Constant TYPE_CONNECTOR_SEGMENTED was renamed to CONNECTOR_TYPE_SEGMENTED
Edge routing is a feature that people have been asking about for a while, and we're introducing it in stages, starting with support built in to the Hierarchy layout.
To setup edge routing you need to instruct your Hierarchy layout to generate routing information, and you need to configure the new edge routing plugin:
Here we see the same dataset rendered in direct mode - we still assign a separate location on each vertex for each edge, but we do not route the edges in an orthogonal way:
We've added support for inputs of type number to both our dialogs and inspectors. The inspector will respond to change events caused by the user clicking on the increment/decrement buttons, enter keypress events, and blur events.
You can see number inputs in use in our Image Processor starter app, for some of the various transformations and filters:
Start a free trial
Not a user of jsPlumb but thinking of checking it out? There's a whole lot more to discover and it's a great time to get started!