When I uploaded the nodes to the flow/node collection, I noticed that the page was using the type and not the paletteLabel value of the node definition:
Is that intentional? Seems confusing for the end user since the paletteLabel is shown in Node-RED if defined, else the type.
On line 107 what is the type? Is it the node definition including the paletteLabel, so that the addition of def.types[t].paletteLabel = t.paletteLabel could already work?
In the template the line would then be something like (pseudo code):
it depends what is indexed in the schedule, I'm not sure what is/isn't indexed for each node/type paletteLabel might not be in the indexed object for example.
The problem here is that while the type is guaranteed to be unique between Nodes, I don't think that the palette label is. It would surely be just as confusing to people to have something non-unique? For my nodes, the palette label is the same as the node name.
But that's why there is a category - so I might well have nodes with the same paletteLabel but they will hopefully be in different categories.
The convention of using type as the label begs the question why have the paletteLabel field in the first place? I notice that most packages use type as label, but I found this - because of the global namespace - too risky, hence my use of paletteLabel and prefixing the types with a package related prefix.
A globally unique namespace is probably, in the long term, not a good idea. So some convention for namespacing types would probably be required in the long term.
Nodes with the same type will lead to broken flows since the flow might well assume a type that was something completely different when the flow was built but having added a new node collection and suddenly boom, flow is broken.
This is also an attack vector for malicious packages that may redefine the base types such as switch, change and function (for example) and using paletteLabel to hide that fact. Does flows.nodered.org check for "known" or "reserved" types btw?
This is about how the node is shown in the palette, not the workspace.
If a node doesn't specify a custom paletteLabel then it will display the type.
As you've noted, type is a global namespace, so need to be unique. That can lead to unwieldy type names that don't look good in the palette. So being able to have a palette specific label is useful.
There are also cases where a node wants to "rebrand" itself, but not have to modify its type (as that would break existing flows). We did exactly that with the rbe node that got renamed filter - by updating the palette label but not changing the type.
Is this global namespace something that the maintainers of Node-RED see as problematic? I can definitely understand that for the target audience of NR that a global namespace isn't an issue.
However as might have come clear over the past few months, I really would like to see Node-RED used for a broader range of applications and in that context, a global namespace could become problematic.
One thing I constantly run into is that there are no NR playgrounds like there are Jupyter playgrounds. When talking to friends about NR it's hard to point them to a demo site where they can get a feel/taste for NR.
I definitely don't want the maintainers to change their development plans or spend resources to fulfil these visions/hallucinations, just wondering for me if this has come up before in the NR community? Has anyone setup a read-only server just for having a look at NR? Are there plans for something like that?
compared to the long list of other problems/issues/new features ?... not really It is something we recognised early on, and does come up now and again, but has not been a major issue.
As for playgrounds - initially Node-RED was part of the Raspberry Pi full install and was there by default. (It isn't now as they ran out of space/ got a bit bloated so went for a more sensible default install). If you run docker then you can easily run docker run -it -p 1880:1880 nodered/node-red to start up an instance in read only mode. I know that isn't a public playground - but for that someone needs to host and pay for a dedicated server, and set up tooling around it to wipe/maintain it.
And of course there are companies such as Nick's Flowforge that offer free online trials.
Crops up only very occasionally. Usually when someone has cloned an existing node, made some changes and published as something "new". Or when a node developer chooses a name that is too generic. Really no different to any other project that allows public extensibility.
Any project with the ability to have extensions provided by the public faces the same issue. But Node-RED has 4382 registered extensions as of this morning and is a project that has been going for over a decade. In all that time there haven't been more than a handful of instances, all of which were easily dealt with or worked around.
Really not sure how that relates to broader use?
Wow! Just tried searching for "node-red online" on Bing and NOTHING came up! Doing the same search on startpage.com came up with these on the first page:
https://playground.mindconnect.rocks is fun - you're dropped straight into a read-only Node-RED instance, no idea what it's doing but you have the instantaneous gratification of the NR experience!
I guess that is kind URL I would give tech friends to say: this is Node-RED! No docker, just an URL and off they can go.
Concerning the global namespace, flows.nodered.org does do a name check "Nodes have unique names" so I guess there can't actually be any clashes. So it's all rather academic
), I believe it shouldn't to difficult, only time being a factor for the Maintainers.
