I needed to get a nested property from an input message, so I wrote following snippet
$scope.$watch('msg', function(msg) {
var someNestedPropertyValue = RED.util.getMessageProperty(....);
}
However I get "ReferenceError: RED is not defined", and then I realized I have never used before this kind of stuff in a UI node (or Template node) ...
So the question is, how to continue with this:
I write my own getMessageProperty function (based on the one from Node-RED), so anybody can find it here in this discussion.
Something should be added to the core of the dashboard (to support some kind of lightweight RED API), so all node developers can use it (at least if that dashboard version is installed).
This is browser side right ? I think the msg that arrives there via the websocket is not the same as the one arriving at the node. You would need to do any getMessageProperty type work before sending to the browser.
Indeed I can use RED at the server side, before sending the message to the client:
beforeEmit: function(msg, value) {
// Get the the value of a nested property from the input message
var someNestedPropertyValue = RED.util.getMessageProperty(msg, "some.nested.property");
}
But I don't need the nested property value on the server side, I need it at the client side.
With that setup, I need to get all the nested properties on the server side and convert them to non-nested properties:
beforeEmit: function(msg, value) {
// Convert the nested property to a non-nested property.
msg.someNonNestedProperty = RED.util.getMessageProperty(msg, "some.nested.property");
// To avoid confusion, remove the nested property from the input message
...
}
Then indeed I can use the msg.someNonNestedProperty on the client side without having to traverse through the nested properties...
Is that what you mean, or am I misunderstanding you?
If yes, it seems like quite a workaround when I need to flatten my entire input message...
the getMessageProperty is really to help the user be able to specify a property like "payload.foo" (as a string) and for it to get msg.payload.foo correctly (which msg["payload.foo"] will not do...and also to give access to flow and global variables. If you just need normal access then you don't need the util.
In the upcoming version of the contextmenu node, you can specify -via a typedinput - in which (nested) field the X coordinate will be delivered:
So I thought I needed to send the input message to the frontend, and read it there. But do you mean that I should get the nested property in the beforeEmit, and create a new message from scratch without nested fields (so my frontend doesn't need to be able to read nested properties)?
Julian, can't find it on your Github repo. Can you share a link please?
That is the in the editor window - so yes when you get the actual property from the dashboard you can then set it into the correct property in the beforeEmit and then send it out. (But it sounds like you may be adding loads of options to the node - why not fix the property to send it out on ?)
Well there are not really much options on the node. Previously there where two ways to specify the position of the contextmenu: a fixed position or via msg.position. But due to our other discussion, the SVG node doesn't send an msg.position anymore. To allow the Contextmenu node to read from ANY input message field, I'm adding TypeInput fields to the Contextmenu node:
Fixed positon:
Msg-based position:
So I need to be able to read nested fields. Although now I'm not sure anymore whether I should do that on the client or server side ....
