Autocomplete of the message object in a function node

Core Development Feature Requests
1

Hi there,

You have a heavily loaded message object and the debug window is visible, maybe one message object is expanded.

You are in the function node writing some JS and need to reference one of the myriad of objects you placed in the message object.

Yes you can click "copy path" in the debug window(we all love it), but autocomplete would be so so much quicker and cooler. The autocomplete could use the objects found inside the message objects in the debug window as its source.

Cheers,

Chris

2

You seem to have missed the copy value button, next to copy path.
scratch that, did not see this is a feature request.

3

The issue is that the function node has no idea what message (or its contents) will arrive next (or in the future). It could literally be anything.

4

How would your function node know which debug output object to select for auto-complete?

5

The flow will of course have to be executed at least once before autosense can help itself to the goodies contained in the message object in the debug window. Just like the "copy path" is only useful after the flow has been executed.

1 Like
6

It would use all currently displayed message objects in the debug window. It would be up to the user to set a filter as needed in the debug window.

Another idea would be an "add this message object to autocomplete cache" button beside the "copy path", "copy value" and "Pin open" options on message objects in the debug window.

I like this second option. Thanks for challenging me on where to get the data.

Edit typo

1 Like
7

Where is the advantage time/click saving? If we have to click add to auto complete then select the auto to fill, i see no difference than copy value and paste direct from debug.

8

I can see a rough path to making this work. The debug sidebar could certainly keep a record of the message properties it has seen whilst the editor is open - that would be better than nothing. The question would then be whether we're able to expose that in a way the monaco editor is able to pick up dynamically.... something to look for after 3.1 is released.

9

Not designing now… but… here be dragons… re performance and fast moving debug flows, caching data volumes, discarding , etc

10

That could be hundreds or thousands. Filtering in the debug panel would be far from intuitive.

That might work though the 3 existing icons are already rather crowded.

Totally.

Worth a look certainly, would be potentially nice to have but not at the expense of performance and usability.

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.