I have a function node called “Diff” returning an empty array (for now).
And I want to reference the result of the “Diff” node in a Telegram message.
But I don’t see how to reference the result.
From what I learned so far I thought it should be something like
{{$node["Diff"].json[0].join(' ')}}
Shouldn’t the results be listed in the variable selector?
What am I missing?
Are both nodes connected?
The problem is that you do not return an object. Everything in n8n is written in a way that what gets returned under “json” is an object and because you return an array instead it does not work.
If you change it to return an object with the property “data” which contains an empty array it should work like expected.
Thanks for the quick reply. Indeed I am returning this
return [{ json: [ ] }];
which does not show up until I turn it into
return [{ json: [ "1" ] }];
While I think n8n is pretty great, this whole passing data structures around can get pretty frustrating. “json”, “data”, “binary” - oh my. Especially when writing functions it feels too lax.
So I should really be returning:
return [{ json: { data: [ "1" ] } }];
Which then apparently can be used inside the expression like this
{{$node["Diff1"].data["data"].join(', ')}}
But the data["data"] is especially confusing.
[ // results of node["Diff1"]
{ // result 0
json: { // representation?
data: [ "1" ]
}
}
];
There isn’t even a data["data"] - there is a json["data"].
And do I only have access to the first result from the expression?
Wouldn’t this make much more sense?
{{$node["Diff1"][0].json["data"].join(', ')}}
It seems like wrapping it in an object does not fully solve this. The nodes shows:
[
{
"old" :[ /* 184 items */ ],
"new" :[ /* 184 items */ ],
"diff": []
}
]
but the selector does not show the empty array for “diff”.
Yes agree, $node["Diff1"][0].json["data"] would have made much more sense. In between the “json” property was called “data” but thought that it was too generic (as both the json and binary would fit as “data”) so I changed it to “json” to be more specific. Was however also not a big fan of that one, so I was hoping to find a better name and then replace it everywhere. However never found a better name and then forgot to change it. That is why we are now kind of stuck with that. The only solution I can think of right now is to simply make both work. Then I could change the documentation to “json” and the Variable-Selector but would so not break existing workflows.
You have access to all the results. To keep the code simple and the UI it however simply always just chooses the first one in the preview. When the workflow executes, it then chooses the first one for the first item, the second one for the second and so on.
Have that on my to-do list for a long time but as there are many more important things to do I never got to it. Also still think that for now, it is OK like that unless somebody really hates it and maybe creates a pull-request.
In the Function-Node it is possible to really hardcode it to a specific item.
That it does not display the empty array in the Variable-Selector is a bug. You should also not forget that it is only an imperfect helper to make things simpler. If it does not display something, you can still change the expression to whatever you need. The whole Expression-Editor is also something I am also not a big fan of and hope to totally change in the future. It simply takes to long to select variables and the highlighting breaks all the time.
If there is any chance I’d highly recommend preparing a migration path and deprecating the old way. It would greatly improved the coherence of the overall system. I can totally sympathize to the naming struggle. That said it still does not explain the missing result index. (as in $node["Diff1"][0])
I think in general I would have picked a different strategy for the data structure that is getting passed between the nodes. But for one you have spent much more time thinking of things that I might be missing, and secondly that’s now water under the bridge. That said - maybe it wouldn’t be such a bad idea to think about some migration strategy to allow for some easier flexibility for future changes.
I think you misunderstood my comment there. I was referring to the expression - not the UI. Basically the missing index I was mentioning further up. Here as comparison:
{{$node["Diff1"].data["data"].join(', ')}}
{{$node["Diff1"][0].data["data"].join(', ')}}
How to access the second result in the first version/line?
Yes, I noticed the highlighting to be quite buggy. I am aware that it’s just a helper, but given how confusing the expressions I found to be - it was really helpful. And the fact that an empty array does not show, really threw me off.
And in the end you want to people to grasp the tool without resorting to bug you in this forum 
Thanks for the help!
About the missing index. I agree that it could be very helpful to also provide a way to access a specific item in an expression (like you wrote with something like $node["Diff1"][0].data). The much more common use case (probably 99%) will however still be that people want to automatically access the item of the current iteration and that is what expressions got optimized for.
Not sure at all if it was the best decision (and that is true for almost everything in n8n). It is quite possible that not, that is what we have for now. I hope however that over time it becomes very clear what things should be changed that it can be improved in future versions (so input like this is very helpful, thanks!). For some things, it will be easy and for some, it could be complicated till impossible. Think without it should be possible to make it also work (without breaking the current way) with an index. At least without having thought about it too much or checking the code.
TBH it is very unlikely I ever need the index - but when it comes to learning the ins and outs of the tool, it would be greatly beneficial to be consistent. The more easily people can grasp how things work without bigger surprises the better.
But did you see this? This sounds like a bug:
Ah yes, that is what I was talking about here:
@tcurdt Just checked. Fixing that bug would take up quite some time. So does not make any sense as the issue is not that bad and I prefer to use my time on something with a bigger impact. That bug will then get fixed when a new and improved Expression-Editor with Variable-Selector gets created.