Exposing settings to the editor

Exposing settings to the editor
Can anybody clarify this feature by answering a few of my questions? Please type slowly and assume I know nothing. :nerd_face:

  1. Does adding this feature give me a global setting shared between my nodes?

  2. Is there an interface somewhere that allows a user to edit the settings.js file or is that done manually?

  3. Setting exportable: true allows the user to override my value with a value set in settings.js or does that do something else?

  4. Can I access this value in my node's settings page and change it there and will that use the normal validation lifecycle?

  5. And most importantly, do you have any real world examples of where and why this would be used? Any public repos that take advantage of this feature?

Hi

    • Yes.
    • No. Currently done manually as being js it can contain hard to parse/format/verify code.
    • Yes - that is the purpose.
    • Yes you can access - but generally not set by the page as that is what settings.js does for you.
2 Likes

Thank you for that fast clarification. That leaves me with 1 final question when it comes to utilizing the setting. I see that it is easily accessible in the node's settings editor as RED.settings.myNodeSomeSetting. I am missing the docs showing how to access it on the backend. Can you enlighten me, please? Thanks for the tutelage.

It should be the same... RED.settings.myNodeSomeSetting

1 Like

Thanks. That was the first thing I tried and get undefined each time. I must be doing something wrong. I though maybe there was a getter method on the settings object that I was failing to find.

p.s. I am pretty sure I am atleast setting it correctly, because I can see the value in oneditprepare .

You are setting it in settings.js ? (and restarting Node-RED)

1 Like

Only setting it in the registerType function, not in the setting.js

RED.nodes.registerType(NODE_TYPE, UiMp4FragNode, {
    settings: {
      uiMp4fragHlsJsSource: { value: HLS_JS_SOURCE, exportable: true }
    }
  });

I ensured that the naming format complied with the warning. Constantly reboot server after I edit.

A couple clarifications to Dave's replies

All of the settings can be set by the user via their settings.js file. The exportable flag determines whether that setting is exposed in the editor as well as the runtime.

But the value should be considered read-only.

If you have set exportable to true, then yes, you can access the value in the edit dialog of your node. But you cannot change its value from there.

1 Like

What is the value of NODE_TYPE here?

Sorry, I defined some const because I am making my boiler plate code for my nodes structured as classes.

const HLS_JS_SOURCE = 'https://cdn.jsdelivr.net/npm/hls.js@latest/dist/hls.light.min.js';

const NODE_TYPE = 'ui_mp4frag';

node-red gave me that warning that my settings must beging with uiMp4frag. then i changed it to comply and it stopped warning me.

Ok. I think I misunderstood the api. If I want the setting available in my backend node constructor as RED.settings.myNodeMySetting, then it must be defined in the settings.js or it will be undefined. If I want to make it available to the settings page, then I have to also add it when using registerType. I thought that the backend could access the default value set during registerType. Sorry for the confusion.

What I have gathered is that I can check if the setting is defined from settings.js before registerType is called. I can update the value and make it visibile in the settings dialog page as informational showing the user which lib is being used along with instructions to edit it in settings.js and reboot the server.

1 Like

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