🪲 Node-RED Bug? Debug output does not include named properties

[TotallyInformation]

Hi all, bit of a weird one for you - not sure I can really class this as a bug but it is certainly slightly off-spec.

When you send something to a debug node and it contains an array. The debug panel does not show any custom properties that the array may have, it only shows the numbered properties. However, if dumped to console, the custom properties are shown.

0|Node-RED  | 6 Sep 15:36:49 - [info] [debug:output]
0|Node-RED  | {
0|Node-RED  |   _group_: { quantity: 83681 },
0|Node-RED  |   France: [
0|Node-RED  |     {
0|Node-RED  |       region: 'Oceania',
0|Node-RED  |       country: 'France',
0|Node-RED  |       product: 'file',
0|Node-RED  |       sales: 784501.16,
0|Node-RED  |       currency: 'EUR',
0|Node-RED  |       date: '4/6/2020',
0|Node-RED  |       quantity: 691,
0|Node-RED  |       customer_name: 'Godart Mouget',
0|Node-RED  |       customer_email: 'gmouget0@epa.gov',
0|Node-RED  |       customer_address: '4 Center Road',
0|Node-RED  |       customer_city: 'Avignon',
0|Node-RED  |       customer_state: "Provence-Alpes-Côte d'Azur",
0|Node-RED  |       customer_country: 'China',
0|Node-RED  |       customer_postal_code: '84913 CEDEX 9',
0|Node-RED  |       order_id: 1
0|Node-RED  |     },
...
0|Node-RED  |     _group_: { quantity: 3164 }
0|Node-RED  |   ],

Hard to see in the example but I have a function that I'm writing that transforms an arbitrary input table (2d data, CSV, etc) into a hierarchical grouped object. The function allows for aggregation at each grouping level. The inner group is always an array of objects (as was the original input table).

JavaScript allows Array's to have custom named properties and I've made use of that here to add the _group_ property at every level including the inner arrays.

This works perfectly in the browser or in a Node.js app. As shown in the Node-RED log, it works in a function node too. However, the debug panel does not display the custom property. Which technically is incorrect I think?

Thoughts? Does this need raising as an issue?

[knolleary]

It is a known (to us... perhaps not explicitly documented as its a bit of an odd edge case) limitation of the debug sidebar with no easy solution (if I remember the conclusion of the last time I dug into it).

[TotallyInformation]

@knolleary

its a bit of an odd edge case

That is certainly true! And normally I would try to avoid it. But it just happens to fit nicely for this use-case which is a really common ask for data reshaping of tabular data and for which I've not found any really decent JavaScript libraries.

My intent is to publish this to npm in a way that lets it be used as a Node.js module (cjs and ejs), the browser (as both IIFE and ESM) and as a node-red node.

Been meaning to do this for ages but I just happen to need to be wrangling an awkward dataset at work right now so have the impetus. Also been wanting it for some of the more complex zero-code uibuilder output options.

It isn't the end of the world, though ideally I suppose it should be in the documentation.

[Steve-Mcl]

@TotallyInformation

The debug panel does not show any custom properties that the array may have, it only shows the numbered properties.

As you know, anything not a primitive is an object. (null is an object, Buffer is an object, Array is an object etc).

const a = [1,2,3]
console.log(typeof a) // object

So that is why an array "allows" custom props to be added.

Some points worth mentioning :

• These extra properties are not included in JSON serialisation, and would be thrown away if you do anything like arr = arr.slice(1);.
• Also, if the array goes through any of its prototype methods (map, filter, etc.) the property won't be transferred to the new array, since the method was put on an instance of Array. Probably expected but should be aware.

Lastly, I have done this is the past, but now avoid it having been burned.

[TotallyInformation]

Thanks Steve, having given myself a bit more time to cogitate, I think I'm coming to the same conclusion.

Like many "clever" ideas, I foresee it creating future issues.

So I suspect that the output of the function will have several top-level properties, one will be data which will contain the grouped table. Another will be summary or some such, containing the same groupings but with only the aggregated data.

The function will most probably become a class so that it is possible to create an instance that will encapsulate the data and the methods to manipulate it rather than having to recreate each time. That won't be so helpful for the Node-RED node version but will be very helpful for the other versions. So that it should be possible to change individual records and have the aggregations update automatically without necessarily a full recalculation. Well that's the idea anyway - we'll see how complex it gets and whether I give up on that part!

Anyway, thanks for the thoughts.