Issues with loading async list for drop down in edit dialogue

Developing Nodes
2

Hi @Roaders,
I think this discussion is about a rather similar issue. In my media node I get the config node (on the client side), but I send the config node properties to the server side endpoint (since I don't know whether it has been deployed yet):

configNode = RED.nodes.node(configNodeId);
             
// All client-side config data should be send to the server (since we don't know if it is dirty or not).
var configData = {};
configData.hostname = configNode.xaddress;
...
$.getJSON("onvifdevice/profiles/" + configNodeId, configData, function(profiles) {
   ...
}

Then in the endpoint on the server-side, I try to find the config node (and if I don't find it, I use the config node properties that the client side has passed):

var configNode = RED.nodes.getNode(req.params.config_node_id)

// Get the profiles of the camera, based on the config data on the client, instead of the config data
// stored inside this config node.  Reason is that the config data on the client might be 'dirty', i.e. changed
// by the user but not deployed yet on this config node.  But the client still needs to be able to get the profiles
// corresponding to that dirty config node.  That way the config screen can be filled with profiles already...
// But when the config data is not dirty, we will just use the profiles already loaded in this config node (which is faster).
// See https://discourse.nodered.org/t/initializing-config-screen-based-on-new-config-node/7327/10?u=bartbutenaers
configNode.getProfiles(req.query, res);
...

Note that my Onvif nodes are still in beta phase, so the logic might not be entirely correct yet!
Perhaps this is not exactly a solution for your problem, but it might give you an idea of how you can solve this ...

I don't know that... Hopefully somebody else can join the discussion.

Bart