Breaking change version 2.0.0

Although we try to avoid breaking changes, this is unfortunately always possible ...

Version 2.x.x contains a change, that might disrupt flows that have been created with the 1.x.x version! However for existing nodes the legacy mode is enabled (see further), to keep using the old behaviour.

What has changed

Suppose the selector field (in the 'Events' tabsheet) is path[id^="ball_"] for a 'clicked' event. This means that a clicked event will be fired for all path elements, whose id starts with 'ball_...'

Suppose the seventh ball is being clicked, then the 1.x.x version would send an output message containing this info:

msg.elementId = 'path[id^="ball_"]'
msg.selector  = undefined

This is not correct! The msg.selector should contain the "selector" column value, and the msg.elementId should contain the real id of the element that has being clicked.

Therefore the 2.x.x version will send an output message containing this info:

msg.elementId = 'ball_7'
msg.selector  = 'path[id^="ball_"]'

Summarized: the msg.elementId of the output message now contains the real element id, and not the CSS selector value anymore!

Short term workaround - Legacy mode

To avoid having impact on existing flows, the legacy mode is activated automatically for old nodes:

When this checkbox is selected, then version 2.x.x will behave exactly like version 1.x.x. Which means that the msg.elementId will still contain the CSS selector instead of the real element id.

However it is advised to deselect this checkbox, and fix the flow (see "Long term solutions" below).

Long term solutions

There are two ways to solve it:

• You can use msg.selector (instead of msg.elementId) in your flow. Indeed the msg.selector field now contains the value of the "Selector" columns, which was previously send in the msg.elementId.
• You can change your flow to keep using the msg.elementId, but then you need to have a look at how the real element id looks like (compared to the selector value).

How did we end up in this situation

Originally in the beta versions of this node, events could only be applied to a single SVG element (id). Later on in version 1.x.x. we added support for CSS selectors. At that moment we decided to keep the msg.elementId naming convention (to store the CSS selector), for backwards compatibility. However we need to fix this now, to make sure you can benefit even more from the powerful CSS selectors in your flows...

An example

Following example explains a bit the difference between a (CSS) selector and the real element id. In the "Events" tabsheet you can specify the "selector", so we know which SVG elements need to trigger that event.

In the selector column you could simple specify the element id (syntax #id), but you can instead specify any available CSS selector!

For example: suppose you have a christmas tree, and you want a 'click' event on every ball. Which means an output message needs to be send, as soon as a ball in the tree is being clicked.

• You could specify a separate event handler for each christmas ball (one event per ball id):

  

• Or you can specify one event handler that needs to trigger event for all balls!

  

  Indeed the selector field is path[id^="ball_"]. This means that a clicked event will be fired for all path elements, whose id starts with 'ball_...'.

  But to be able to know which ball has been clicked, the output message should contain msg.elementId = 'ball_7'.

That is the reason why this (breaking) change was so important...