[ui] Multi-line variable values and helios upgrades generally

[philrenaud]

This started as an attempt to allow multi-line variable editing in the UI (#19543) and turned into a larger effort to replace the Variables UI's use of common components with Helios components

Resolves #19543

[github-actions]

Ember Test Audit comparison

	main	a49391b	change
passes	1540	1540	0
failures	0	0	0
flaky	0	0	0
duration	10m 51s 546ms	10m 58s 780ms	+07s 234ms

[philrenaud]

This long disabled attr says "Don't let the user add more fields if their last one is currently empty"

[gulducat]

This translation helps, thanks!

little style nit: sometimes I like (some of) the attributes being placed on separate lines, for big mouths-full like this. I still might not know how to interpret the semantics of the frontent magic, but some whitespace can help me follow the syntax, e.g.

Suggested change

	<Hds::Button @text="Add More" @color="secondary" @size="medium" @icon="plus" class="add-more" type="button" disabled={{not (and this.keyValues.lastObject.key this.keyValues.lastObject.value)}} {{on "click" this.appendRow}} data-test-add-kv />
	<Hds::Button
	@text="Add More" @color="secondary" @size="medium" @icon="plus"
	class="add-more" type="button"
	{{! disabled if the bottom variable's key or value boxes are empty }}
	disabled={{not (and this.keyValues.lastObject.key this.keyValues.lastObject.value)}}
	{{on "click" this.appendRow}}
	data-test-add-kv
	/>

and makes room to include that interesting {{! comment }} syntax to leave notes in the code.

Is there a reason not to newline-separate the bits like this?

Also, now arranged like that, I wonder: is class="add-more" type="button" needed at all? Isn't it being supplanted by <Hds::Button ... @icon="plus" ?

[philrenaud]

This, and the entry set above it, are side-effects of the Helios input component not doing two-way data binding. For some additional context, two-way data binding is kind of a bygone convention in most JS frameworks at this point so it's not that weird, but we were using that bygone convention for quite awhile. Now, we are explicit about "When you do something that indicates needing to save something, save it".

In this case, that happens in the template on keystroke ({{on "input" (action this.setModelPath)}}), but it's also common to do this on element blur, on form submit, etc. We're just eager beavers here.

[philrenaud]

An astute observe may note that some of the <Hds::Table>s here have a @columns property, where others do the <:head as |H|> and H.Tr thing. Helios tables allow us to do either, and the best argument for doing the former has to do with sorting being baked in.

[juliezzhou]

lgtm

[gulducat]

I found some nits to pick, but nothing really blocky, so overall LGTM!

[gulducat]

This translation helps, thanks!

little style nit: sometimes I like (some of) the attributes being placed on separate lines, for big mouths-full like this. I still might not know how to interpret the semantics of the frontent magic, but some whitespace can help me follow the syntax, e.g.

Suggested change

	<Hds::Button @text="Add More" @color="secondary" @size="medium" @icon="plus" class="add-more" type="button" disabled={{not (and this.keyValues.lastObject.key this.keyValues.lastObject.value)}} {{on "click" this.appendRow}} data-test-add-kv />
	<Hds::Button
	@text="Add More" @color="secondary" @size="medium" @icon="plus"
	class="add-more" type="button"
	{{! disabled if the bottom variable's key or value boxes are empty }}
	disabled={{not (and this.keyValues.lastObject.key this.keyValues.lastObject.value)}}
	{{on "click" this.appendRow}}
	data-test-add-kv
	/>

and makes room to include that interesting {{! comment }} syntax to leave notes in the code.

Is there a reason not to newline-separate the bits like this?

Also, now arranged like that, I wonder: is class="add-more" type="button" needed at all? Isn't it being supplanted by <Hds::Button ... @icon="plus" ?

[philrenaud]

@gulducat growing textarea on input is a good idea here. Let me see if the Helios masked input can support data-replicated-value css, but even the state of the art for solving this ( https://css-tricks.com/the-cleanest-trick-for-autogrowing-textareas/ ) is kind of hacky. Going to give it some thought.

Update: made an issue for it