How to create a hidden node property

Developing Nodes
1

I am trying to create a hidden node property ("moddable_manifest") in a contrib node, in order to provide a property in the nodes exported JSON, where the JSON should be something like

{
    "id": "39f01371482a60fb",
    "type": "pid",
    "z": "fd7d965ef27a87e2",
    "moddable_manifest": {
        "include": [
            "path/to/manifest.json"
        ]
    },
    ...
}

The purpose is explained here

I have only a little experience with creating nodes and am obviously missing something. Possibly I am on the wrong track completely.
In the node's html file, in the defaults section I have added

            moddable_manifest: {
              include: [
                "path/to/manifest.json"
              ]

and in the UI section there I have

<script type="text/x-red" data-template-name="PID">
    <div class="form-row">
        ...
    </div>
    ...
    ...
    <input type="hidden" id="node-input-moddable_manifest">
</script>

I can see the hidden field in the page html in the edit screen, but it does not appear in the exported JSON. Can someone tell me what I am missing please?

2

Hi @Colin

I have no experience with node-red-mcu.
But what happens when you do (putting it under value)

defaults: {
  ...
  moddable_manifest: {
    value: {
      include: [
        "path/to/manifest.json"
      ]
    }
  }
}

This will set the default value for the hidden field
There is no such property of include on the property API in Node RED? - at least I don't think so :sweat_smile:

BUT! when you export - it should end up with the JSON below

{
    "id": "39f01371482a60fb",
    "type": "sensor",
    "z": "fd7d965ef27a87e2",
    "moddable_manifest": {
        "include": [
            "path/to/manifest.json"
        ]
    }
}
3

Thanks, that was it. I should have looked more carefully at the other defaults entries.
I didn't need the hidden field spec in the UI section, I didn't think I would need that but put it in when my initial attempt failed.

1 Like
4

Hi @Colin !

This "procedure" is only necessary, if you intend to add an additional manifest at runtime.
If you just need e.g. a special driver for your node, you may simply put this into the manifest.json you have to create anyway for your custom (MCU) node implementation.

5

This isn't for a custom node, it is for an existing contrib node. I was planning to follow @phoddie's suggestion in the linked discussion:

This property may also be a good way for a Node-RED contributed node to signal that it is compatible with Node-RED MCU Edition. The presence of modadble_manifest can be considered an indication that the author intends for it to be used with the MCU

I imagine one could, for example, put in there the fact that it is safe to preload it.

1 Like
6

You don't have to make this detour - if your intension was just to add a manifest.json for your contrib node. Take the manifest the plugin created as template, modify it to your demands & drop it in the directory next to your standard Node-RED files.

It will be found there by the plugin and injected / utilized as necessary.
And if you defined the preload option, your contrib node will of course be preloaded ... :wink: !

7

That only works if using the plugin, rather than node-red-mcu without the plugin. Also, if I understand correctly, that would be a manual operation that would need to be performed every time the node was used.

Is not providing it once with the node itself more of a shortcut than a detour? Perhaps I don't understand something relevant.

8

That's true. I wonder yet how relevant this is...

Not sure what you mean. There's no manual op necessary ... if you're working with the plugin. If not - see above.

9

Doesn't that conflict with

10

Not at all - yet my description was perhaps a bit short.

You don't need more than a manifest.json file in the same directory as the rest of your (standard Node-RED) files, e.g. next to your package.json @ node-red-contrib-pid.

If you intend to separate things, you could create a dedicated folder (labeled mcu) to place you node-red-mcu related files there.

In both cases, those files will be found and used as intended ... if you let the plugin do its job :wink: !

In fact, when you're currently using a contrib node, the plugin already checks for the existence of a manifest.json at one of those locations ... and if not found, creates the necessary file for you - but in the working directory.

For reference, you may have a look at any of the already existing implementations of nodes dedicated to node-red-mcu, like e.g. node-red-mcu-gate.

11

That is exactly what I was proposing to do.
I believe that the purpose of the addition of the manifest property to the node is to allow this tobe read when the node is used other than with the plugin.

12

I'm aware of that.
So you create a flow, export it to ... another editor, copy/paste additional stuff ... then open a terminal, issue a build process manually & follow a flow (!) by its javascript representation --- rather than pressing a single button & enjoying the integration of node-red-mcu into the Node-RED environment?

I won't do it that way, but that's up to anyones preferred way of acting... :wink:

13

No, for my experiments I have installed node-red-mcu (as a git submodule) inside my .node-red folder, and all I have to do is to run mcconfig from that folder. The advantage is that I have everything under git control, including the node-red-mcu version. See here for exactly how I have done that.

The reason I went down that route was because at that time my flows would not run using the plugin. I think all those problems have been fixed, but I can't easily run the plugin with the Beta version of node-red so I can't switch over yet. I have submitted a PR to allow that but it has not been merged yet.

14

There will be an open beta for the next version of the plugin released "soon" ... in the coming days.
This is going to support NR 3.1.

16

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