Autocomplete variable parameter with the variable selected in the variable editor

[D8H]

Also:

• Create new variables with the type "Number" by default instead of "String".
• Use the type of the previous child to add new variables to arrays.

[4ian]

Will this work with arrays?

[D8H]

Yes, for array children, it does something like MyArray.3. It's probably not what users want if they add an array and have one of its children selected, but I guess that's ok.

Do you think we should remove the child for these cases?
I guess, at some point, the field could choose according to the type of variable that is needed.

[4ian]

Do you really need to depend on selectedNodes? This means any state change will also change all the callbacks using setSelectedNodes. Previously, this was a stable function.

[4ian]

Try this instead:

const [selectedNodes, doSetSelectedNodes] = React.useState<Array<string>>([]);
const setSelectedNodes = React.useCallback(
  (nodes: Array<string> | ((nodes: Array<string>) => Array<string>)) => {
    // Use the functional update form to access the current state directly
    doSetSelectedNodes(currentSelectedNodes => {
      const newNodes = Array.isArray(nodes) ? nodes : nodes(currentSelectedNodes);
      if (onSelectedVariableChange) {
        onSelectedVariableChange(newNodes);
      }
      return newNodes;
    });
  },
  [onSelectedVariableChange] // Remove selectedNodes from dependencies
);

[arthuro555]

Create new variables with the type "Number" by default instead of "String".

Hmmm... Is this decision based on user research?

Personally I find myself using strings more often than numbers, and to prefer strings as a default, since I can still write a number in there, then change the type. I personally do not find myself always going through the fields I configure from left to right/top to bottom, but to jump ahead then back depending to fill in fields I assume I might forget first, and the value I settled on setting the variable to is something I am more likely to forget than they type I want to give the variable.

In fact I never was frustrated by the default type being a string, but am very often irritated by Arrays children not being strings by default....

[D8H]

Hmmm... Is this decision based on user research?

Personally I find myself using strings more often than numbers, and to prefer strings as a default, since I can still write a number in there, then change the type.

Looking at examples, games mostly use number variables. Strings are usually directly set on text objects. I guess that strings variable are mostly used for the state of FSM.

Could it be that you often work on network related features which probably requires things like string id?

In fact I never was frustrated by the default type being a string, but am very often irritated by Arrays children not being strings by default....

Good new for you, arrays now use the previous child type.

[D8H]

These changes has already be merged by:

• Unify variable instructions and handle local variables #6459