StringArrayEditor revision and update

[Gazook89]

This is basically an implementation of what I wrote in #3466. It restructures the DOM of the StringArrayEditor and adds more functionality, such as better keyboard interaction. It removes what I consider "extra buttons" which I don't see used in many other tag editors/inputs. The styling is yet unfinished, but even at this stage is more inline with existing HB styling.

Keyboard

context	action	result
new text in new-tag-input, or editing existing tag	, | Enter	submits text as tag and focus new-tag-input
focus within tag-container (unless in input)	ArrowLeft | ArrowRight	moves focus left/right through tags and new-tag-input, within tagContainer
focus on existing tag	Enter | Space	open tag and focus input for editing
focus within input in tag or new-tag-input	Escape	blur/exit input without submitting, move focus to tag
focus on existing tag	Delete	delete existing tag
focus on element prior to tag-container	Tab | Shift + Tab	move focus to new-tag-input, skipping existing tags (instead, use arrow keys to navigate thru individual tags)

Things I want to hammer out:

• fix: need to take datalist options as a prop-- currently its static and shows same list for tags and authors.
• fix: if an input inside an existing tag is cleared out (everything is deleted) and then you move to the next tag, by pressing Enter or ,, the original text is reset and the tag isn't deleted.
• fix: if using Delete to delete characters after text cursor, the whole tag is deleted.
• fix: prevent 'resetting' of input text when you hit Space while editing an existing tag.
• do not use .invalid styling when input field is empty, but still prevent entry of empty tags
• allow entry of tag schemes (meta:, systems:, etc) using either upper or lowercase, but convert to lowercase when submitted.
• if using backspace in existing tag and no text remains in input, it throws a non-breaking error in console...should prevent that.
• fix: only render datalist if datalist prop exists
• factor in the issue mentioned in draft PR Tag trim #3284
• fix: the cleanValue() method on stringArrayEditor is too specific to one instance of the component (brew tag editor), and has no application for other instances (like 'authors' input). Need to figure out how to pass that type of 'value manipulation' in as a prop? The crux is that the current 'validator' is lenient on the tag scheme case-- it can be entered lowercase or uppercase-- but we actually only accept lowercase here, and cleanValue() was used to convert it to lowercase on submission. So maybe a validator prop and a acceptedValue prop?
• check accessibility (semantic html, aria roles)

Things I might want to do in this PR, but maybe not:

• convert to functional component
• preserve width of tag when switching between "editing" and "not editing"

Things I might do if this PR is merged:

• rework the css for metadataEditor, to reduce duplicate or unused styles. Possibly separate out the styles for each component (or at least some of them, and utilize css variables to control in metadataEditor.less)

Related Issues:

• fixes Tweak tags schemas #2333
• fixes The StringArrayEditor component returns error if you ESC out of it #3462

 

• datalist on tags entry #2335
• Clarify reason for invalid tag input #2357
• emit tag classname as lowercase on userpage #3166

Relevant PR:

#3469

[calculuschild]

Is this more intuitive...

I see what you mean but I think the added clutter negates most of the benefit.

[Gazook89]

yeah, and it would be a problem if for some reason more 'special' categories were added...you'd have to keep adding more inputs.

Another idea is to make each tag two inputs-- a dropdown for the tag scheme (meta, type, etc) and then a scheme-specific combobox. The left button throws a dropdown, and the chosen value determines which datalist is presented in the right-hand side combo input.

Further, it could still allow typing meta:theme in the right hand side for convenience, and on 'submission' would split the tag scheme portion to the left hand side (if valid). My example above should have a 'blank' option, as well. For regular tags, just type in the right-hand side.

The Author's StringArrayEditor/TagInput would still need to be more basic, so I'm not sure if the proposal above would just be a different component, or a configuration of the same component. But just throwing ideas out.

[ericscheid]

In the meantime, I had another idea: what if we just used simple tags that aren't "compounds" of "meta:" + "blah" for the input, instead just using different tag input fields for those categories and then turn them into compound tags after entry...so the UI would look something like this:

Additional to the clutter aspect, this creates the risk that a user will enter a tag into the wrong field. Compare the combo field, where typing "ad" filters the droplist to type:Adventure and also system:AD&D in the same droplist.

[calculuschild]

Another idea is to make each tag two inputs-- a dropdown for the tag scheme (meta, type, etc) and then a scheme-specific combobox. The left button throws a dropdown, and the chosen value determines which datalist is presented in the right-hand side combo input.

This is kind of along the lines of what I was thinking when I wrote "Is there any way to trim it [the datalist] down initially with just the major categories or something, and then transition to the full list once the user starts typing?" I.e. make the datalist a two-step process, first picking the scheme and second filling out the tag name. Though I only pictured it as one single textbox.

I am intrigued by this "dual-tag" approach. I say we give it a shot.

[Gazook89]

Discussed briefly in gitter: going to move forward with working on something like the below. Likely I will use a library like FloatingUI to handle the anchor positioning of menus (skipping CSS Anchor API for now since it is only available in Chrome and I don't want broken menus in firefox). Likely I will be working on improving the Combobox.jsx component first, possibly splitting out the "datalist" portion as it's own thing which is then imported to combobox, and add a few props.

Styling isn't locked down at this point.

[calculuschild]

@Gazook89 Is this PR paused for now? Wondering if I should move it out of my priority list if this needs to simmer some more.

[Gazook89]

Pause it for now-- I just haven't been as plugged in to VSC over the summer as I've got other projects going on (both house stuff and other things). I wouldn't be bummed if someone branched off this and got it over the finish line, either (but I'll come back to it eventually too).

[Gazook89]

This PR is going to close soon, in favor of a new branch. I would keep this PR, to keep the comments and such, if anyone confidently knew if it was possible to basically take my new branch and drop it in to replace the existing branch for this PR. But I'm not going to worry about that.

The new branch will be a functional component, but otherwise will have all the same targets as this branch did (and hopefully be more clear). The add, remove, and edit functions on the new branch are working as of right now, but I haven't published it yet.

I just want to give a heads up in case anyone has any last comments to throw here.

[5e-Cleric]

We can close after referencing the branch, that should be enough.