Node-red-contrib-ui-svg : server side logging

[BartButenaers]

Hi folks,

A big disadvantage of the 1.x.x versions of the SVG node was the poor error reporting. Indeed when a user made a mistake, it was very difficult to determine what was going wrong. So got lots of questions since then, and most of the time I had to start my debugger to find the root cause.

And most of the time it was one of the following mistakes:

• An unexisting element id due to typo
• A mix of topics and unrelated commands
• An unexisting command due to typo
• ...

Therefore I really wanted to improve the error reporting in the upcoming 2.0 release. So now the "panzoom" branch on Github contains following changes:

• A series of validations have been added on the server side. In case of issues an error/warning will be logged in the debug sidepanel (via node.error and node.warn) and the message will be ignored in the dashboard.

  

• Unfortunately lots of errors cannot be validated on the server side. E.g. when a user enters an unexisting element id (or css selector) then we only know that when in doesn't exist when we arrive in the dashboard (i.e. when the element id doesn't exist in the client side DOM tree). And looking at the browser log is very hard, e.g. on smartphones (where you need to setup a remote usb connection...).

  To simplify the troubleshooting process, you can now activate this new checkbox:

  

  From now on the errors inside the dashboard will also be displayed on the server side in the debug sidebar:

  

  Remark: when N drawings are visible at the moment (i.e. N dashboards running simultaneously), then N duplicate errors will be displayed (where N can be 0)...

Hope this will assist our users in their drawing experience...

@Steve-Mcl: when the msg.payload contains an array of objects (each of which has its own command): then I ignore the entire message - in the server side validation - when I find 1 incorrect object (e.g. 1 unexisting command). Is that ok? In the 1.x.x version the client side skipped all correct objects in the array, but it processed the correct objects.

As usual all 'constructive' feedback is more than welcome!

Bart

[Steve-Mcl]

@BartButenaers

@Steve-Mcl: when the msg.payload contains an array of objects (each of which has its own command): then I ignore the entire message - in the server side validation - when I find 1 incorrect object (e.g. 1 unexisting command). Is that ok? In the 1.x.x version the client side skipped all correct objects in the array, but it processed the correct objects.

Hi Bart, I'm not quite getting this (perhaps a typo or two?) or I am tired and a little out of touch. Would you might re-reading/checking/updating (and add a sprinkling or reference) please?

[BartButenaers]

Hey Steve,

Suppose you have an input message containing two commands in the payload:

"payload": [  
  {
      "command": "update_style_oepsie",
      "selector": "#my_circle",
      "attributeName": "rotate",
      "attributeValue": "transform(180deg)"
  },
  {
      "command": "trigger_animation",
      "selector": "#my_rectangle",
      "action": "start"
  }
]

But the user made a typo by adding "update_style_oepsie" instead of "update_style". As soon as 1 of the objects contains an error, I report that 1 error and I skip the entire message (so it won't be processed by the client side).

In the 1.x.x version the client side would ignore the first incorrect object, but it would have processed the second object.

[Steve-Mcl]

That makes more sense

@BartButenaers

I report that 1 error and I skip the entire message (so it won't be processed by the client side).

So does that mean

1. when there are (for example) 3 commands - if command 2 is an error then command 1 would be performed, command 2 would error & command 3 would not be processed?

OR

2. are you going to validate all commands before executing any of them?

TBH, I'm not certain which is better?

1 could have side effects and 2 nothing happens (bar an error). Not sure which is better?

Also, what constitutes an error? Just an invalid command? Or if selector is invalid? Or if setting of value is bad?

[BartButenaers]

@Steve-Mcl

what constitutes an error? Just an invalid command? Or if selector is invalid?

That is a good question. Because I added first the server side validation, and afterwards the extra client side logging. But now both come together, and it might indeed need to be reworked a little bit.

Use case 1

Suppose you inject a message with an array of 3 objects, and only one of those has an incorrect command:

1. Object A has a valid command
2. Object B has a invalid command
3. Object C has a valid command

First you have the server-side validation of the message: as soon as I see one error (in this case the command of object B) then I trigger node.error and I skip the entire message!

Reason why I did it like that: since the user injects multiple commands in a single message, I assume that those commands belong somewhere together. So if I only process a couple of those, you will get an inconsistent state. I consider it like a complete transaction: commit or rollback

Seems there is something wrong in the logic of the flow, and the user needs to correct it!

Use case 2

Suppose you inject a message with an array of 3 objects, and all of those have a valid command:

1. Object A has a valid command
2. Object B has a valid command (but the selector refers to a non-existing SVG element id)
3. Object C has a valid command

The server-side validation will pass the message to the client, because - based on the info that we have available - everything is ok (i.e. the 3 commands are valid).

Once we arrive on the dashboard:

1. The CSS selector will be executed for object A and the command will be executed on the discovered SVG elements.
2. The CSS selector will be executed for object B but NO SVG elements will be discovered. I have added here some logging to show an error about this to the user (in the console log or in the Debug sidebar if the new checkbox has been activated).
3. The CSS selector will be executed for object C and the command will be executed on the discovered SVG elements.

So on the client side it is not an all or nothing operation...

So perhaps it is better to act the same on the server side: show a non-blocking error and send the message to the client anyway. Except when I see that all objects have an invalid command, then it has no use to send it to the client (because nothing can be processed there anyway).

Hopefully this is a bit clear ...

[BartButenaers]

BTW the new checkbox is not only useful for input message validation. Because it also reports errors when an unexisting element id (or incorrect CSS selector) has been entered in the config screen. For example:

Then you don't have to guess anymore why it doesn't work.

P.S. some people might wondering why we don't show these text fields (on the node's config screen) in error (red border around it), and the node in error (red circle in the flow editor). But that is not possible since the CSS selector searches the client-side DOM tree for matching elements, and we don't have that information currently on the server-side available. Unless we ever add a server-side DOM tree to our node ...

[Steve-Mcl]

@BartButenaers

So perhaps it is better to act the same on the server side: show a non-blocking error and send the message to the client anyway. Except when I see that all objects have an invalid command, then it has no use to send it to the client (because nothing can be processed there anyway).

I dont know Bart both are good.

I guess we just choose a route or ask the community which is better - but in a succinct way to encourage a responce (i'll try).

Question to anyone who has an opinion...

• If an array of 3 commands are injected into a node, that are intended to be sent to the client to adjust 3 properties in the DOM, should we...
  • A) First validate all 3 commands & STOP if any are invalid
    OR
  • B) Skip over invalid commands and send the valid ones to Client

@BartButenaers

Unless we ever add a server-side DOM tree to our node

Dont go there

[greenembrace]

I'm not sure that I completely understand the whole issue, but my preference would be 'A' above, errors should become apparent as soon as possible. Letting somethings slip through may produce subtle side effects.

[Steve-Mcl]

Thanks for taking the time to read through that and reply.

Im still torn & hope more folk reply.

I didn't want to influence the decision by revealing my mindset on this but this is what I think...

"Be forgiving". I.e. HTML is very forgiving . JavaScript is quite forgiving. imagine the web today if every mistake or glitch threw up an error box (a bit Ike internet explorer used to in the early days - yuck)

That sways me to option B.

[greenembrace]

Hi Steve, yes OK i'm swayed too. i'm writing micro-controller C++ at the moment and it is a pain.

[BartButenaers]

I'm also thinking now to rewrite option A to option B. Because when you make other mistakes in the input messages (which can only be checked on the client side like e.g. element id's ...) then it will also do partial updates. In that case the user will notice it and needs to correct his input messages...