Just explain in words a sample flow that you're trying to do, and I would be happy to slap together how I would do it.
Not sure if that would be more or less helpful though. Like we've all said before, there are probably a dozen different ways to do it - all technically fine.
Still not sure why you would want/need all the boolean true/false stuff - that just isn't how I do my logic - but no matter.
If you want to use the function node like that, then do it the way dan said. That is the easiest way to do it with the assumption that you want to use your function node like that.
That is hard to answer without knowing what you are doing with the boolean logic.
Need to understand the big picture to say how I would do it. And who knows - maybe I would do it the same way? I definitely use function nodes for some of my mode based lighting logic - just not as boolean true/false on the output.
For instance, here is a standard motion lighting (2 motion sensors) with no function blocks, but it does different things in 2 different modes. Could have made it 1 Hubitat command block on the right if I used a function node, but I like not using function nodes when I don't have to.
(note to self, probably needs some logic on the "on" path so that it doesn't send an ON command every motion detection event - so this isn't a great/perfect example...)
Let's focus on the motion sensor M-K and go upward.
M-K is my kitchen motion sensor.
If it is "active", it gets the current mode (function with 3 outputs). O1 = home, O2 = away, O3 = sleep. The function sets home as (true, false, false), sets away as FTF, and sets sleep as FFT.
If O1 or O3 are True, then based on the time, I either turn on the kitchen tube lights or the kitchen wall lights.
If O2 is True (away mode), then I check the state of two switches (Visitor and Pattie Poehl). If either of those are true, then it feeds into the same time based light selection.
That seems fine to me, other than fetching the mode. If you wanted to leave it all as-is, and just stop fetching mode then replace the Current Mode fetch block with a change block that shoves flow.house_current_mode into a msg.payload.mode (or other) variable, and use msg.payload.mode as your variable in your function node.
Or delete the mode fetch node altogether, and then do the flow.get in your function node. I would probably do it this way, since you are going to have the function node anyway.
Obviously need to set that mode variable somewhere else, too.
It will definitely be faster. How much? Dunno. I haven't found a reliable way to measure millisecond log info in node-red. All I know is a mode fetch on my system takes something < 1s... So I'm not 100% sure this will speed things up greatly for you?
Logically, I should cancel it. I have 46 autosomes and an X chromosome that say "Cancel it". But my Y chromosome says quite clearly, "Nah - I don't think so".
I'm a Y advocate. I got a NUC about 6 years ago. One of my best buys ever. It has been used for so many things over the years.
Windows 7/8 media center pc.
Windows 10 "kitchen" computer.
Ubuntu server to host Docker with a TON of containers including my HE influxdb/Grafana/NR.
Now it runs Home Assistant in docker on top of Ubuntu.
Trust me..worth the purchase one way or the other.