Best practice to avoid using Change node at every junction for topic matching?

TotallyInformation/node-red-contrib-events: Event broadcast and receive nodes for Node-RED. EXPERIMENTAL. (github.com)

They look interesting to use in some niche cases, thanks! :slight_smile:

Yes, certainly niche, not intended to replace normal node-red processing and especially so now that there is a return option available in the core link nodes. I published them because I had a need for the processing in uibuilder and needed something that didn't require you to manually select the source/destination pair. But they can be handy if you need a different way of working than the link nodes provide. Thankfully, the nodes a really simple and so should be very reliable.

1 Like

I think that without serious study of the Unreal Engine programming model, I have learned as much as I can from your screenshot. Obviously, not all flow-based programming languages are the same, and there is a lot of discussion in the literature and online as to how to classify them and describe their features. If your goal is to reproduce exactly Unreal Engine programming in Node-RED, you may not be able to avoid issues like the one you describe. Using msg.topic to identify the source and type of an input may not be the best approach. If you look through the descriptions of NR core nodes, you will find some that use msg.filename, msg.reset, msg.parts, and many other properties to tell downstream nodes how to process a message.

This is simplified for properties like the ones I mentioned. JavaScript is not strongly typed, so tests are needed, but these variables clearly need to be a string, boolean or number, respectively.

@drmibell Very useful info! Thanks a lot!

Will check that out! Thanks!

Thank you so much for these details! Now I got the idea. Up until now, I failed to see how the JS async nature would affect the message boundary detection.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.