Yes, it can.
No, I don't think that is a good idea & it should not be necessary.
However, it is open source so you are free to clone it and create your own version.
Thank you @TotallyInformation for your response.
If settings.js is enough to hide the Node-RED palette, I’ve been trying for a couple of days but it doesn’t work. Could you please help me with what changes I need to make in settings.js?
Thank you @lgrkvst for your response.
I think that to modify the source code like you did, it’s necessary to understand the objects and architecture of Node-RED. Do you have any information, PDF, or link that explains how Node-RED works — its architecture, folder/file structure, and the role of each file?
Can I ask why you don't use the un-minified version of the js file? It seems like a giant maintainability headache using the minified version. Also are you that interested in upgrading with each new release of NR? I tend to stick to one version of NR and extend out from there.
When I created dead red - the head less node red - I moved to using RED.max.js so that I could better make changes and locked on the version 3.1.3. If I do want to update that code base, what I have is a retrieve script that obtains everything needed to run the NR frontend - including nodes and plugins frontend code.
I extended that script for Erlang-Red (which implements NR in Erlang) to work for NR version 4.x. I regularly update the NR codebase when I update the nodes installed - i.e., I have a source NodeJS Node-RED installation where I install and update nodes and plugins. When I have done a node update, I subsequently copy the codebases of that installation to Erlang-Red using my retrieve script. Finally I implement any backend functionality in Erlang. Rinse and repeat.
The point here is that it's a structured methodology in copying the NR frontend. Admittedly an upgrade of the NR version would be difficult but I have no ambition to do that. If I were to start a new project, for example Rust-Red - NR in Rust - then I would take the latest version of NR and extend from there.
Hi @gregorius,
It seems you have very deep knowledge of Node-RED.
Could you please guide me step by step on how to hide the default Node-RED palette and replace it with my own custom palette?
This is the first task I need to complete. After that, I plan to add a low-code GUI that will allow developers to add new custom components.
I'm currently stuck at this point and not sure where to begin.
Thank you in advance for your help!
Short Answer: No.
Long Answer: Sorry, No.
First off I know nothing of how the palette works, neither do I want to.
Second I have my own projects to get on with (else no deep knowledge) .
Third I suggest that you take the perspective of @kevin192291 and offer to pay someone to help you.
Fourth what benefit would I have in a "step by step guide" of how customise the palette? I've done much writing on NodeRED and created several node packages yet no one knows how to use the sponsor button at github.
Fifth I don't do unpaid consultancy work - any longer, I'd rather do stuff that interests me. If there is an overlap to what others are interested in, then so be it.
I don't mean this answer to be disrespectful, I'm just being blatantly honest. Folks seem to think that because its "open source" everything is "free" as in financially free. That is not the case. Even open source developers have to pay rent and food and insurance and taxes and water rates and drugs - my landlord doesn't tell me that his apartment is "open source" and I don't have pay because its "free", no no no, he comes every month (as sure as death and taxes) and wants money from me. He's not interested in how many folks I helped in my open source activities, nor how many lines of code I created and that were then open sourced for the betterment of society. Nope. All of it does not interest him. The only "interest" he knows is the interest on the money he's making on the rent I'm paying.
EDIT: P.S. This view is totally and absolutely my own and does not in any way represent anyone else here in the forum, the Node-RED community or in fact, the universe. So please don't think I'm speaking for anyone else other than for myself.
4 Likes
@gregorius:
Thank you very much for your honest and detailed response.
I truly appreciate your contributions to the Node-RED ecosystem, and I fully understand that your time is valuable and that you have other priorities.
My intention was never to ask for free consultancy, but rather to learn from those with experience. Your perspective is completely fair, and I respect it.
Wishing you continued success in your work and projects.
Best regards,
1 Like
You can remove the standard nodes from the palette by including in your settings.js something like
nodesExcludes:['90-exec.js','28-tail.js','10-file.js','23-watch.js'],
which will stop those nodes from being loaded.
To include your additional nodes it is merely necessary to install them as normal.
1 Like
I'm actually altering a red.max.js, just calling it red.min.js to fool the editor to swallow it.
Me being curious about Erland-Red would be an understatement. What made you write it, and what would you say are the main USP's? Performance I get, but how?
Are you using Phoenix for communication middleware? Could you let me in on your reasoning on that account? Also, did you ever consider breaking the 1:1 between client and server nodes, and let for instance a single server template node serve all clients?
Are you using a per-instance process for contexts and node configurations?
Do you plan to maintain it?
Performance yes but probably not what you think. The performance of developing software in cooperations with non-developers, to improve the communication between "stakeholders" and developers. The ability of a visual solution to provide a holistic overview versus textual based solutions is what fascinates me. The potential to do better than Jira tickets, Scrum meetings and Agile methodology to software development - all being textual centric with static, immutable imaginary to help transport complex and shape-shifting goals.
Additionally Erlang-Red aims to bring the ideas of visual flow based programming (FBP) to a new developer community. One that is fascinating mix of academics and industry for something that is basically passed its prime. Think: Rust & Go here that have taken the place of Erlang in developers imaginations - not to mention Elixir which strips Erlang of all the good bits only to replace them with "ruby-like" constructs that pretend to hide the difficulties of a creating a working Erlang architectures. Elixir has good goals and I think that's fine but Elixir seems to be limited to the application of Erlang to the web - this is something that Erlang-Red does not aim to be.
No. Cowboy, this is an Erlang project because Erlangs key selling points (independent , message communicating processes and immutable data structures) fit incredibly well to the fundamentals of FBP. I am literally amazed that in the ten years of Node-REDs existence, no one else has done this. But I can imagine why.
I also have Elixir integration via a separate library (for markdown and csv) but at its core, Erlang-Red will be Erlang. Some have asked "why not Beam-Red" - because that simply does sound good - beam me up scotty. Plus others can create Beam-Red and Elixir-Red that's why I want to create a body of standard unit tests to define the standard behaviour of Node-REDs core nodes - that way other projects and test their implementation with a "standardised" visual test set.
Communication between nodes is Erlang message passing. There is no need for an extra framework to facilitate that. Cowboy does the entire web stuff and the rest is Pid ! Msg. Message cloning is for free. Events are messages. There are many gen_servers that maintain states and supervisors to restart stuff if things break. I.e. all the good bits of Erlang are utilised.
Done that - I tag the websocket and add it to a cookie. For each combination of node and websocket tag, a separate Erlang process is created (i.e. nodes are represented by proceses). Each message is passed to the right combination of websocket tag and node id ensuring that a end user, who is identified by the websocket, has their own execution space.
It was indeed something I saw right at the start and that I wanted to have - since I didn't want a server farm but only a single server for multiple clients.
Nodes have a per-process context, flow & global contexts can be simulated by using either statemachine or gen_server. And I think I will leave it at that, I don't think I want to implement flow and global contexts because they simply don't fit into the Erlang world.
Addressing a developer community versus a "user"community means that providing the basics and allowing others to experiment is important. Node-RED has a fundamental different approach because the "users" aren't the "developers", i.e., developers create nodes and users, use them. I want Erlang-Red to merge those two - i.e. the users should become developers and developers can extend and experiment with Erlang-Red. It's bit like: Emacs v. Word: users of Word don't extend Word, Emacs users extend and user Emacs.
This idea goes back to my USP: bring visual FBP to a developer community. That's why I originally created flowcompare developers need a structure visual method for comparing flow versions, that's why I created flowhub developers need a structured visual version control mechanism, stakeholders need diagrams, that's why flow2UML.
It's like a child, it's a 7 day a week job, it gets me up early and it requires a lot of attention. But the nice thing is that it doesn't get me out bed in the middle of the night to change nappies or feed it.
But as all good children, eventually it has to be standing on its own two feet and go out into the world, I can't be babysitting it all its life. And so it is with Erlang-Red I will continue on as long as I see a reason to continue. If that goes, then Erlang-Red will gather digital dust.
However, with every new project, I fundamental become more fascinated about how well Erlang and FBP fit. So the experiment will continue for a while yet.
P.S. I worked with Erlang before doing this project. I didn't start from scratch coding Erlang and many of the Erlang concepts were known to me.
Thanks for thorough answers – I really appreciate it.
One more question: You're basically looking for an editor. Why Node Red? Wouldn't you want something that gives your Erlang processes classical FBP, with back-pressure and dataflow processing as well as control flow processing?
Sorry misread your question, “why” node red? Have you got a better tool that has all that plus is open source and easily extended? If so, let me know! 
No I don't. Node Red has a quite feature-complete and battle-tested editor. I was just thinking that if I were to go down your road, I would maybe consider basing a solution on for instance rete.js, and add whatever editor capabilities that made sense in a BEAM world.
No no, check out flow based programming and then compare that to Erlang. Then when you realise that FBP is the basis for node red, then things make sense.
Back pressure is not a topic in Erlang: let it fail and recover is the motto. You design systems that recover not system that attempt to stay stable … completely different mentality.
