[NEW NODE] node-red-contrib-primitive-status

Share Your Nodes
1

I have released version 1.0.0 of the node-red-contrib-primitive-status node.

A Node-RED node that displays the primitive type of msg.payload in the nodes status. Messages will pass through the first output, and the primitive type is returned as a string from the second output.
The node requires no configuration.

This is my second node published, please critique it, I'm new to coding and want to get better.

2 Likes
2

Maybe add (optional?) msg.type to output 1?

3

As it is passed to the status already it could be caught by a Status node - so is the second output even needed ?

4

I wanted to leave the message on output one alone as a pass-through for debugging, and not altering the message. And to have the second port for additionally instructing the flow based on type, or counting/classifying types of messages.

5

Status node? I'm not sure I follow what you are saying, could you elaborate?

6

Actually, I get what you mean now.

7

Hi, at first I thought what is the point of this node but from a low code point of view it's not actually a bad idea.

Personally, I would have just one output and add the type to a msg property. E.g. msg.propertyType

That way, you could have a switch node after your node that permits routing of the message based on type.

Also, I'd permit the user to test more than just msg.payload (e.g. the user might want to route messages where msg.res is an object)

Lastly, I'd be inclined to test further than primitive type. E.g a buffer, an array & many other well-known prototypes are described as an "object". However you could test the object with Array.isArray and Buffer.isBuffer etc.

2 Likes
8

I do want it to be able to test more than just msg.payload. (I'm kind of new to coding so this may take a bit to figure out).

It can handle array, but I should add buffer as well (despite the node name). And thank you, I really appreciate the input.

1 Like
9

Can't you do that already with the isOfType test in the Switch node?

10

True. But then you'd still not see the type name on the status without adding a function node. I was only suggesting how I'd approach it to make it a bit more useful (low code being the focus) tbf Colin. Personally, I'd just use typeof and node.status in a function but I can see some benefit for those not so clued up.

1 Like
11

At first, this approach seems a good one :slight_smile: ...... but ......

It's much easier to do stuff further down the flow if the message itself is carrying ALL the information

If you make it optional, then everyone is happy :slight_smile:

12

... but if all you need it for down the flow is for a switch then just use a switch... and if the switch node doesn't have the correct options for type then maybe that should/could be enhanced...
If you just want it to be visible then it's fine as-is

1 Like
13

Adding msg.type to first output is supported as of version 1.0.2

1 Like
14

:slight_smile:

So next, maybe let user change what it's called (in case msg.type is used by another node in the same flow)

Just suggesting these things as a way to develop your node creation skills :slight_smile:

3 Likes