Hi
One feature I wouldn't mind having would be that if I were using a node, and I selected that I'd like to use a flow, global or other type of context variable, then all possible existing variables in that context be made available in eg a dropdown list.
eg if using an inject node, and I want to fill msg.payload with the value of a named existing global variable, then if I select global (or flow) then I am able to choose a variable that is already set.
This functionality is very similar to that which exists with eg boolean, where if that is selected I can choose true or false from a list.
At present I have the context data open, and copy and paste variable names from there.
Ideally this would be general functionality, rather than be node-specific.
This may have been considered before, or perhaps it even exists (feel free to point me in the right direction), or the current arrangement may be a result of a requirement to allow free text entry for variable names in that field.
You mean enable autoComplete with flow/global env keys?
I think I read somewhere that there is a limitation but it might be useful to explore the question further. I find autoComplete useful 
2 Likes
Hi Team,
I had some time to work on it 
There is also logic to limit the number of calls to recover the context.
It looks like this (yeah looks like msg type):
The link to the commit.
@knolleary tell me if I can open a draft PR so you can modify it becauseI just have one problem that I don't know how to solve because I don't know enough about all the possible options.
When the type changes, autocomplete is not destroyed then when changing manually the autocomplete type is destroyed but not instantiated. Options should be undefined but that's not the case.
@GogoVega funnily enough, I spent some time on this as well last week. Got a rough proof of concept working - but with plenty of areas to improve. Please do raise a pr. I can compare approaches and see how best to move forward.
1 Like
hopefully only one call per config window rather than for every field.
That would be ideal but for that need much bigger logic in order to update only if an editor window is opening. I'll see if there's a simple way to do it
Iād imagine it would be part of the logic that triggers the oneditprepare event
This only needs to do anything when a user types into a typedInput for flow or global type. That logic is all contained within the typedInput and doesn't depend on anything else.
It doesn't require multiple calls to the runtime as it can cache results. I have all this working in my local branch.
Please could you publish your branch so that I can educate myself (to understand your logic)? 
so it has to do a fetch every time a typed input field gets focus ? (or after one char typed ?) as how does one field know another was updated recently enough not to need to update the cache ?
(and may as well extend to env variables while you're at it 
It gets a list of completions when a user starts typing in a field. That list will either come from the runtime, or a local cache.
Does the cache contain global data and for all flows?
I've focused more on global right now to get the poc working locally. There's more to do before it can be shared - the code is a messy of experimentation at the moment.
This includes updates to the runtime APIs to be able to get lists of keys rather than the more expensive queries we already have that returns the values as well.
1 Like
If you modify the API in this case the idea would be to create a cache in the runtime with all the data and create an endpoint which sends only a list of keys for the type of context and the given depth so as to limit the query size. (as you say in part)
The focus can be used to perform the first query but it will be necessary to perform others as soon as the depth changes.
Restrict the number of queries to just one is not really possible with this way, the only advantage (with this way) is that the query is small. Don't forget that a single loading means that the snapshot is the same for the entire duration of the browser session.
Calling back a couple of days after posting my feature request - would just to say thank you to all those looking at this.
1 Like
If adding an endpoint for autoComplete is not a problem then let's do things more cleanly.
As a general rule it is better to do a single query with all the data rather than one query for each data (I know Steve would agree) but for our use, we mainly want to reduce the size and therefore increase the number calls.
I specify that the first call is only do once when the user starts typing and once for each new depth. The cache will be on the runtime so as not to overload the editor.
If it's ok for you, I'll edit my PR to add the endpoint.
As mentioned, I already have a lot of this in place in my local branch. You're welcome to duplicate the work in your branch, but it'll make things harder to merge to bring this together.
Duplicate the work is not very productive but I would like to take a look at your branch to see what remains to be done 
Thanks, I'll take a look
I watched your live but I couldn't send a message in the chat 
I don't know why
