No, but is being noodled.
I'll give you a very simple one from my perspective:
Let's say I have something like this:
[
{
"id": "63048ae3e4754083",
"type": "link in",
"z": "1106c83583311c54",
"name": "link in 6",
"links": [],
"x": 195,
"y": 280,
"wires": [
[
"d370450c55398a57"
]
]
},
{
"id": "d370450c55398a57",
"type": "function",
"z": "1106c83583311c54",
"name": "Permissions Check on User",
"func": "\nreturn msg;",
"outputs": 2,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 360,
"y": 280,
"wires": [
[
"904556915f671323"
],
[
"d2c54fec30f6046b"
]
]
},
{
"id": "89bfb9d58e4ba1dc",
"type": "link out",
"z": "1106c83583311c54",
"name": "link out 17",
"mode": "return",
"links": [],
"x": 655,
"y": 280,
"wires": []
},
{
"id": "d2c54fec30f6046b",
"type": "function",
"z": "1106c83583311c54",
"name": "function 25",
"func": "\nreturn msg;",
"outputs": 1,
"timeout": 0,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 535,
"y": 300,
"wires": [
[
"eeeb781cb6547aa6"
]
],
"l": false
},
{
"id": "904556915f671323",
"type": "junction",
"z": "1106c83583311c54",
"x": 520,
"y": 260,
"wires": [
[
"51c1c13e1d448a34"
]
],
"l": false
},
{
"id": "51c1c13e1d448a34",
"type": "junction",
"z": "1106c83583311c54",
"x": 550,
"y": 260,
"wires": [
[
"eeeb781cb6547aa6"
]
],
"l": false
},
{
"id": "eeeb781cb6547aa6",
"type": "junction",
"z": "1106c83583311c54",
"x": 580,
"y": 280,
"wires": [
[
"89989a6195691987"
]
],
"l": false
},
{
"id": "89989a6195691987",
"type": "junction",
"z": "1106c83583311c54",
"x": 610,
"y": 280,
"wires": [
[
"89bfb9d58e4ba1dc"
]
],
"l": false
}
]
Alright. I will be able to call this permissions check, which I can modify later, from any function node.
It can also be a "check permissions subflow", yes, with an output, a second function node following on the output.
But now I can just call this permissions check from a single function node if I want to. It will even turn some parts of the function node MORE visual than they were before without this. I can visually (elsewhere) work on what's called inside the function node.
That doesn't exist yet, right? That would indeed be very useful.
Sorry for the 3rd post in a row instead of editing.
Reading the war (in a non-harmful playful little cute chibi toys sense) in this topic took ~1 hour and a half. Quite interesting.
A war (in a non-harmful playful little cute chibi toys sense) of preferences is silly. The problem I can understand is if a new feature ruins the way Node-RED was previously used. It's made for whoever needs it, like me, not for everyone. A new Node-RED user would have a difficult time finding out about it, I don't even know every RED.util.whatever exists. I'll have to look it up someday, maybe there are cool things I don't know about.
This is like saying that env.get('project') breaks Node-RED, because you're supposed to exit the function node, get the env variable with a change node, go back into the (or a different) function node, continue. Why so masochistic? Why not let others simplify their work? "There's no visual indicator that the function node uses something from the environment". Yes. Many things would be cool, and we can ask for.
I appreciate the Node-RED team for giving possibilities for different types of developers. So many things are possible, in so many different ways.
3 Likes
Found a bug that it probably an issue present in other versions too.
-
A typed input with types ["node"] and value "empty" renders as this in both light/dark themes
-
A typed input with types ["node", "str"] (it just needs to be another type besides "node
) and value "empty" renders as this in both light/dark themes
-
A typed input with types ["node"] and with a value renders as this in both light/dark themes
As long as I pass types ["node", "str"] when creating typed inputs, it will render fine. But I would like to be able to pass only "node"
Have schools been bombed in this discussion? Have innocent civilians been displaced by this argument? Have people died in this debate?
I see no "war" here and I would please ask you do refrain from sensationalising a simple debate between adults.
Thank you.
P.S. for some folks the term "war" is kind of a trigger word. Something like saying "Trump is a ■■■■■■■ lunatic" - that also triggers some folks.
Sorry, I've edited my post to make it less triggering. I also have "war" in my name but I can't do anything about that one.
As a follow-up, I do think that a little visual indicator that the function node has a link call inside it is a good idea. I imagine it would be like the "comments inside" indicator but with a a little "link call" arrow. Maybe in the upper left.
3 Likes
What our parents call us is purely their fault. /s
Please raise an issue. Would be helpful to know if it's a preexisting issue - in which case it isn't specific to the beta.
From this point forward, posts unrelated to the beta will be hidden/deleted as off topic. This thread is meant to be about the beta - the more noise the harder it is to keep track of the actionable feedback.
5 Likes
Just a quick question on the UI. Are the palettes meant to be able to float (anywhere on screen), or are they tied to the side panels?
@knolleary can you enable the color and icon params to receive values for light and dark? Some node colors and their icons that are set for light theme dont work well when switching to dark theme. So allowing the node to define different colors and icons for the theme would be nice
API Proposal
icon:
icon: {light: "icon.light.png", dark: "icon.dark.png"} while keeping the current behavior to avoid breaking older nodes
color:
color: {light: "#FFFFFF", dark: "#000000"}
while also keeping the current behavior to avoid breaking older nodes
It seems clear that various tab (mostly) enhancement requests are not going to be in NRv5, or at least not from the start.
Have these been considered and rejected or simply forgotten?
- Deploy Current Tab Only request-tab-level-deployment-option/2666
- Hide tabs from some users ............... }
Insert new tab next to the current one } request-tab-level-deployment-option/2666/11- Buttons to navigate to first tab/last tab }
- Grouped tabs, Coloured tabs (cf node groups) how-to-group-flows
- A "Has description" badge above tabs which have something in the config Description. (cf Nodes, also for Groups)
- Enhanced flow documentation (Groups, not flows) Ways to improve flow [group] documentation
1 Like
Added in 4.1.8. but without default keys.
I can't find this one, but in searching I can see "Add flow to the right" in the dropdown menu, so #3 is satisfied.
- Not on my radar - it didn't get anywhere when originally discussed in 2018 and I didn't see it get brought back to life in February. It is not a trivial change, would need to consider the value compared the work needed to do it.
- Not in the short-term plan. The whole UX around this is hard to get right - especially if it's intended to be secure (user has no visibility of the tabs at the API level) rather than simply cosmetic hiding.
- Done
- Done
- Will happen at some point - just not 5.0
- I don't like the design of having a docs badge on the tabs - not sure what the better approach would be
- Related to 6, the PR won't make it into 5.0, but the discussion will continue
If you want to discuss any of these individual points, please start a new topic. This one is about the beta, not future roadmap discussion.
@bobo the sidebar panels cannot float freely. They are restricted to the left/right hand side of the editor.
2 Likes
I have privately received some criticism for not engaging with the linkcall discussion, and for trying to shut down discussion. Not saying from who as that is irrelevant here - if one person feels that way enough to say something, then others may feel similar. So I wanted to clear the air.
I hadn't foreseen the level of push-back the linkcall feature would receive. I knew it may raise an eyebrow or two, but some of the claims that its 'breaking what Node-RED is' (to paraphrase, not a direct quote) goes much further than I had expected. I wanted to let the discussion play out to see whether that would bring people around on the idea. I was purposefully away from my laptop over the long weekend here in the UK and didn't want to feel pressured of having to keep engaging in the discussion.
When I did check-in on the thread, I could see the temperature was rising. I've been running this forum long enough to sense when threads are at risk of derailing and that splitting certain topics out into their own thread is a good idea. That is not shutting down discussion; its making sure discussion doesn't crowd out others, whilst also trying to keep the discussion productive. I could have proactively moved all the relevant replies to their own thread, but that's a pain to do from the phone UI of the forum and I wasn't in a position to get to my laptop to do it.
On the substance of the linkcall feature, here are my thoughts.
It has been a common request to have a way to have reusable code across Function nodes. I believe the linkcall feature provides an elegant blend of the two worlds.
I have seen real world cases where users have had to write more and more complicated Function code with lots of internal state management in order to manage the ability to pass messages to flows and get responses back into the Function node. That state management is fine for simple cases, but we've seen some truly horrible cases - such as the langgraph work Steve has referred to. The linkcall feature removes 99% of that state management - making the code they have to maintain much easier to understand.
For me, that is a win. In order to solve the problem at hand, many Node-RED users aren't looking for the most elegant "node-red" way of solving a problem - they just need to get the problem solved in a way they understand.
I do acknowledge the feedback about it 'breaking' the visual nature of the flows. But it is no more broken than the situation we already have with the Complete/Status/Catch nodes. They provide no visual indication as to what nodes they are 'connected' to. You have to open the edit dialog to see how they are configured. Yes, that edit dialog gives you the information more easily than scanning though a Function node's code to spot the linkcall uses - but the complaint was about the visual nature.
We already have an issue on the backlog for reviewing the general appearance of nodes. Part of that is looking at how we can add some visual indicator to nodes that have 'virtual' connections to other nodes - and provide a means to navigate those connections. This was already something we intended to do for the existing nodes (Complete/Status/Catch) before the linkcall concept came along - we just hadn't explicitly linked the two thoughts together.
It's unlikely this will happen in time for 5.0, but it will happen.
17 Likes
Well - IMHO it is... if you see one of those nodes on the page you can click on it to see what is connected, and have a way to highlight them... with the linkcall inside a function the link it is calling can be on another tab entirely so no idea what is being called. And vice versa the called link node has no visual clue that it has been linked to from a function node on some other tab... so to me it is somewhat more broken.
Appreciate what you say about a general indicator update - but yes... hopefully this is 5.1 rather than 6.0.
PS - I'm happy to provide a temp fix to at least change the icon if node.linkcall is used.
1 Like
