Requiring a msg structure - enforcing the presence of fields and attributes

Hi,
so looking at this... we don't need a "just validate" mode as that already works if you set it to only output a JSON object and pass in a JSON object... so that just leave the requirement to check the whole msg... In which case should we ignore then delete the msg.schema part (and ignore msg._msgid) so that it only validates what you expect to be the msg ?

2 Likes

I was thinking of something along these lines - a node that validates any of env, flow, global or msg object at the top level, not just a property. Additionally it would be nice if that node could generate documentation of the schema.

The node owns the schema so it doesn't need to be passed in on the msg object - as with the json node and it allows validation of the entire object that needs validation. The holistic json schema validation node does that plus generates documentation for non-developer humans to understand.

I find this particular useful for flows that provide functionality: nodes have clear documentation but flows have no structured representation for requirements. Using a json schema at the entry point to a flow then allows for clear requirements for what a msg object needs in order to utilise the flow.

EDIT: The README is shown correctly at npmjs.com not at flows.nodered.org --> readme has pictures & text, which does not seem to be the case when viewed @ flows.nodered.org (at least for me).

2 Likes

Sorry, I missed this thread previously. There are many examples in existing nodes where classes are used.

In uibuilder, extensive use is made of singleton classes so that a single class instance can be shared amongst the nodes and amongst uibuilder node instances.

Worth noting however that JavaScript's handling of classes has, until very recently, always been rather "slack" shall we say. Only now is it getting true private class variables and methods for example. Certainly I'm itching for Node-RED to move to node.js v16 as its base so that many of the newer JavaScript features become available.

That's kinda what I meant, if I create a class in JS and then did typeof, I'd get "object" - not really a class in the sense of other languages, quoting the CLI:

prompt> node
Welcome to Node.js v18.17.0.
Type ".help" for more information.
> class Fubar {
... }
undefined
> typeof Fubar
'function'
> var o = new Fubar()
undefined
> typeof o
'object'
>

For this use case not particularly useful.

Yes, typeof is a blunt instrument. You need to use something like myobj.constructor.name I think.

Certainly classes are not as fundamental to JavaScript than in Python. However, they are still very useful and getting ever better now that private variables (node v14) and methods (node v16) are available. Of course, constructors and class extensions are also available.

I wouldn't bother to use JS classes for simple tasks but for complex things, they are pretty useful.

Something else suggested Object.getPrototypeOf(myobj)?.constructor?.name was more reliable.

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