5 posts tagged with "jointjs"

One of the key differentiators between JsPlumb and other libraries in this space is JsPlumb's level of configurability - more often than not you'll find that once you hit a blocker in some other library, JsPlumb will offer you the ability to do what you need.

A great example of this is JsPlumb's concept of a DragGroup. Simply put, this is a group of vertices that should be dragged together - but as we'll see, it's not quite as simple as that, and it can be used to great effect with minimal work required on your part.

Active vs passive members​

In this canvas, try dragging the large green box around. You'll see the two red boxes drag along with it. Now try dragging one of the red boxes - nothing else moves. This is because all of the nodes are inside a drag group, but the large green node is marked active and the red nodes are marked passive:

Introduction​

Web Components have been around for quite some time now, but it's probably fair to say that they have not reached the widespread adoption that in the early days it seemed they might. I never really started using them for various reasons:

• Incomplete browser support JsPlumb needs to work on as many browsers as possible and does not have the luxury of requiring the latest browsers. It took quite some time for all of the major browsers to bring their web components support up to the spec.
• Relatively poor documentation Nowadays there's a wealth of articles discussing web components, including a great one on MDN, but this was not the case at first.
• Clunky developer interface This is of course a subjective viewpoint, but it's certainly not just me who thought so. One of the fundamental issues for me was trying to figure out how they could be composed as easily as something like React/Angular etc, particularly when the only input to a web component is through its attributes, and they have to be strings.

Recently I've been looking at web components anew: with the upcoming 7.x release of JsPlumb we're keen to explore all opportunities to use up-to-date technologies, and we thought web components deserved a second look. There seems to be a groundswell of people adopting them, and so we're interested in exploring if there's any value for our licensees in us adding some kind of web components support.

Specifically, we're wondering if we can support something like this:

Many libraries offer the ability to drag elements around, but JsPlumb's drag handler is a little more advanced than most: there are a number of options you can set on JsPlumb to get very fine-grained control of how your users drag elements around. One of these - the constrainFunction - is the focus of our post today, and we'll show you how it can be used to make a simple tile game with the minimum of effort.

Constrain functions​

In this first canvas, you can drag around each of the nodes as you please:

At the time of writing, JsPlumb has a test suite consisting of almost 11 000 unit tests, covering every aspect of the library including its integrations with Angular, React, Vue and Svelte. We like having this many unit tests: it gives us confidence both in the quality of the library and in making updates. When we develop new features we first add a bunch of tests that break and then we update the code until our new tests - and all of the tests we had previously - work.

How do you test a UI built with JsPlumb, though? What are the sorts of things you might like to test? A non-exhaustive list:

• Are my nodes/groups being rendered the way I expect?
• Can users drag edges in the way I expect them to be able to?
• Is node dragging behaving the way I expect?
• Can users edit nodes with an inspector?
• Are events firing in the way I expect?
• Is the integrity of my dataset ok?

One question we hear a lot from prospective licensees is how does JsPlumb compare as an alternative to JointJS? The people at JointJS have taken several stabs at summarizing this but the results can at best be described as an exercise in creative writing.

In today's post I'm going to jot down a few thoughts of our own, plus those of the many developers who come to us once they've reached the limit of JointJS's capabilities.