VSCodeTips is a community of 1,192 amazing vscoders

We're a community that shares tips & tricks on how to best leverage VS Code

Create account Log in
Nick Taylor
Nick Taylor

Posted on

Improved tagging in the editor

My coworker @s_aitchison merged some amazing work that is now available on vscodetips.com.

If you create or edit a post, you’ll notice a really great experience when editing tags now.

If you want to know more about the feature update, check out her Feature update: tag selector post.

And for those interested, here’s the pull request.

Add new tag autocomplete to editor #16025

What type of PR is this? (check all applicable)

  • [ ] Refactor
  • [X] Feature
  • [ ] Bug Fix
  • [ ] Optimization
  • [ ] Documentation Update


This PR finishes up the work on the new tags autocomplete for the editor, replacing the previous tags field with the new MultiSelectAutocomplete (and bringing that new component out of 'beta').

Here's a wee Loom describing the changes and test steps below a bit more

NB: in the Loom I forgot one other feature - if you press your backspace key on an empty input, if you have a previously selected item to the left of it, it should pop it into the 'edit mode'. Also, the eagle-eyed will spot a small bug in the video's "edit post" flow where a tag is changed from s to security - I've fixed this bug!

Related Tickets & Documents

Closes https://github.com/forem/forem/issues/15423 Closes https://github.com/forem/forem/issues/14845 (epic)

QA Instructions, Screenshots, Recordings

(Check out the Loom linked above for a walkthrough of all this)

1. Top tags

  • When you first focus the input "top tags" should be shown, and you should be able to select one from the list
  • Top tags list shouldn't show any items you've already selected
  • When you've already added the maximum of 4 tags, the "top tags" list shouldn't appear

2. Search

  • When you type in the input, search results should be fetched and displayed
  • If there are no matches, whatever you have typed in the input should be displayed instead
  • If you've already added the maximum of 4 tags, typing text shouldn't kick off any search

3. Selecting items

  • You should be able to click an item to select it
  • You should be able to use the up/down arrow keys to highlight an item, and Enter to select it
  • If you type some text followed by a comma (,), the text should be selected
  • If you type some text followed by a space ( ), the text should be selected
  • If you type some text, and Tab or click away from the input, the text should be selected
  • You shouldn't be able to select by any of these means if you've already reached the maximum 4 tags

4. Clearing the input

  • Pressing Escape should clear your current search

5. Editing a selection

  • Clicking the selected tag's name (rather than the 'X') should put it in "edit mode" - i.e. input is moved in place, pre-filled with the tag name, and the previous remove button should be gone
  • You should be able to activate that same button by keyboard by tabbing to it and pressing Enter
  • You should also be able to activate "edit mode" by pressing backspace on an empty input (the previous selection should now be in edit mode)
  • Once in edit mode it should all behave like a normal search

6. Deleting a selection

  • Clicking the X should delete the tag and the input should be focused ready for a fresh search
  • The button should work by keyboard also
  • Placing an item into 'edit mode' then deleting all of the text and leaving the input (e.g. tabbing or clicking away) should delete the tag completely

7. Publishing

  • Tags added should be reflected in saved drafts and published posts
  • When you edit a previous post, the correct tags should be visible by default

UI accessibility concerns?

This is quite a complex component, so definitely some accessibility concerns but I believe I have addressed them. I've tested with VoiceOver on mac.

  • Input/suggestion list conforms to the combobox authoring practices
  • An aria-live confirms when a user adds or removes a selection
  • A hidden aria-describedby communicates the max number of selections allowed
  • aria-disabled="true" is applied to the input when the max selections is reached and no further selections are possible
  • Edit/Remove buttons are keyboard accessible and grouped together semantically
  • Previous focus trap is gone

Added/updated tests?

  • [X] Yes
  • [ ] No, and this is why: please replace this line with details on why tests have not been included
  • [ ] I need help with writing tests

[Forem core team only] How will this change be communicated?

Will this PR introduce a change that impacts Forem members or creators, the development process, or any of our internal teams? If so, please note how you will share this change with the people who need to know about it.

  • [ ] I've updated the Developer Docs or Storybook (for Crayons components)
  • [ ] This PR changes the Forem platform and our documentation needs to be updated. I have filled out the Changes Requested issue template so Community Success can help update the Admin Docs appropriately.
  • [ ] I've updated the README or added inline documentation
  • [ ] I've added an entry to CHANGELOG.md
  • [X] I will share this change in a Changelog or in a forem.dev post
  • [ ] I will share this change internally with the appropriate teams
  • [ ] I'm not sure how best to communicate this change and need help
  • [ ] This change does not need to be communicated, and this is why not: please replace this line with details on why this change doesn't need to be shared

[optional] What gif best describes this PR or how it makes you feel?

here we go

Discussion (0)