Hello Dynamo people!
We are looking at putting a little bit of love into the If Node - specifically enabling lacing with it, but want to do more and make sure it behaves how you wish it would!
We are looking for feedback in this thread on how you think the If Node should function and are particularly interested in real-world examples 
This could be examples you have currently worked around using DesignScript, Python or ZeroTouch nodes, or any manner of nested If statements.
For a single list, we currently have the following solutions:
- Out-of-the-box demarcated in Teal
-
@Andreas_Dieckmann’s awesome Clockwork solution in Orange
- The standard Python solution in Pink
We don’t want to break any existing workflows - so will either add another node or make sure the default behaviour (With lacing) still retains what is in existence today.
The behavior for a double True or double False is as follows:
The behavior for an index matched list of True's and an index matched list of False's is as follows:
And finally, for an index matched list of random True's and False's is as follows:
Question to you all - does the behavior of the Clockwork nodes exhibit what is expected?
If_Node.dyn (78.8 KB)
Why not split it up in IF.ELSE, IF.THEN etc. nodes, like SQL?
Awesome. I think lacing and list levels would go a long way.
Great news, ScopeIf+ from Clockwork is what I use (design script)… I’m also intrigued by Marcel’s suggestion, would an extra input for ‘else’ ‘then’ etc. work?
Hey @Marcel_Rijsmus, do you have an examples where you would want to use both the If.Else and If.Then split nodes? I’m intrigued
Split outputs might be helpful in some situations as well; i.e. separate pass/fail outputs as well as the current “combined” output.
I’ve updated the original post with more context - and another question! 
I think that there is another difference that the examples do not show, the case for a true list with different length than the false list.
The OoTB if node won´t return that last yellow when the test is false. Is this part of what will be addressed by adding lacing functionalities, or is it working as expected?
It’s very much not serving the Dynamo community correctly hence the ask!
Appreciate the feedback @HalfBaked I did indeed miss this case 
Oops.
Heya
Thanks Sol, we all appreciate it
On a related note… Given that the ScopeIf node is pretty dangerous, could we make a big note for people to avoid it?
Or rename it to be more explicitly for node building? (sorry if this breaks people’s graphs, but I can’t say I’ve ever seen it used)
Thanks,
Mark
This particular focus is on the basic If node, but we can definitely also think about ScopeIf
We can’t make any breaking changes (Unless very warranted) to existing graphs until we hit a major version - i.e Dynamo 3.0, of which a single change like this wouldn’t precipitate said upgrade. We could change the hover interaction on help however.
Hi @solamour
I was thinking to make the nodes more self explanatory.
IF ELSE could be used as:
Make a branch that executes when the IF statement results in true.
Else run a second branch of the script.
I just think it would be easier to understand the node.
IF
title == 'The Hobbit' OR
primary_author == 'Tolkien'
THEN
RETURN 'Middle-earth'
ELSE
RETURN 'Earth'
END
what values are returned is different than what code is actually executed - this is why scopeIF node exists and I think it’s important to discuss here as well…
Hi @solamour,
I’m using the Python solution mostly, for the reason mentioned by @HalfBaked (switching between lists of different length).
PS. If you have some love left to give, Levels/Lacing for the nodes AND, OR and XOR would be nice 
.
Hello @MJB-online,
For our UI Nodes we do not typically enable Lacing by design as this is a manual process (ZeroTouch nodes get lacing enabled by default) in the AST. There is a method, but it’s less than ideal (Manual and time consuming) - hence the current lay of the land.
We do have an AND UI Node that is missing lacing, but there is a ZeroTouch equivalent, entitled && that does have lacing Does this work for the use-cases you are after or is more than a two input ports required?
OR has the same state - both a UI Node and a ZeroTouch equivalent.
And our Math.Xor node is also ZeroTouch, with Lacing.
Given the above, what functionality is missing that would help out use cases for you?
Hi @solamour,
Thanks for your comment.
For me, the combination of levels and a flexible number of input ports would be useful in some cases. But I only look at the nodes as an end user. I can’t imagine what that would mean in program code. So if it gives too many problems programmatically, there are always other options .
Keep the current node as it is for backwards compatibility and add a new List.If node that has lacing / list@level options enabled.
The If Node has always needed two things:
- the ability to work with lists of separate lengths
- the ability to return an item if an empty list is one of the options
@solamour
Any updates on this?
