Skip to content

Implement queue selection controls. #14

Closed
campb303 opened this issue Aug 6, 2020 · 8 comments
Closed

Implement queue selection controls. #14

campb303 opened this issue Aug 6, 2020 · 8 comments
Assignees
Labels
feature-request Request for functionality that has not already been implemented

Comments

@campb303
Copy link
Collaborator

campb303 commented Aug 6, 2020

Currently there is no way to select one or more queues in the UI. This needs to be implemented.

I imagine this interface to look and work similar to how Gmail allows the To field of an email to be populated using a combined search bar and Material UI chips.

Example:
Gmail's use of Chips in the To field

The interaction is demonstrated in this video.

@campb303 campb303 added frontend feature-request Request for functionality that has not already been implemented labels Aug 7, 2020
@campb303 campb303 added this to the v1 milestone Sep 14, 2020
@campb303 campb303 self-assigned this Oct 23, 2020
@campb303
Copy link
Collaborator Author

Programatic support for this has been added. The API can now receive multiple and return multiple queues like

/api/ce+me
[
	{
		"name": "ce",
		"length": 48,
		"items": []
	},
	{
		"name": "me",
		"length": 67,
		"items": []
	}
]

Support for destructuring the new data structure has been partially implemented. However, the URL structure will need to be reconsidered to allow both for multiple queues to be activated and single items to be loaded.

@campb303
Copy link
Collaborator Author

This can be implemented using the checkbox example of Autocomplete from MUI. The behavior should be modified to that the top search result is highlights automatically and selectable via the keyboard. After a selection, focus should shift back to the text box to allow for another selection.

@campb303
Copy link
Collaborator Author

campb303 commented Nov 9, 2020

This was implemented here.

Example:
Queue Selection

While functional, there are some things that need improved:

  • The component sends an API request for new queues with every selection which causes unnecessary API calls and re-renders. Instead of calling the API every time the selection changes, it would be better to call the API when the menu closes. This would avoid the unnecessary re-renders and API calls.

  • The component currently remains open after selection which causes it to remain open after a re-render causing an unnecessary click to close it. The list should close on blur to avoid this.

  • The visual presence of the over takes the table when less than 3-4 items are present. This creates an ambiguous UI that doesn't tell the user what to do. A conditional instruction message should be present if no items are selected in the list.

@campb303
Copy link
Collaborator Author

campb303 commented Nov 17, 2020

Next Steps:

Look

  • Address issue with the dropdown not resizing when open and the sidebar changes state.
  • Add conditional instruction message for when no items are selected.
  • Replace close icon with a text button and icon using the closeIcon prop.
    Note: This is awaiting the PR actions mentioned below.
  • Add a visual indicator for asynchronous requests like this.
  • Change default height to make the element the same height whether something is selected or not.

Behavior

  • Review the MUI Autocomplete docs for potential performance improvements.
  • Stop auto population of text on menu item hover.
  • Change behavior to send API request on when the menu closes.
  • Autofocus textfield on page load

Related

@campb303
Copy link
Collaborator Author

The closeIcon prop actually controls the clearIcon prop. See this issue. A PR to change the name from closeIcon to clearIcon is open. A request to expose the real closeIcon is in the works.

@campb303
Copy link
Collaborator Author

Dropdown sizing during state change and endAdornment prop replacement still need to be addressed but all other todos have been completed. Merging this into staging and making it available for testing.

@campb303 campb303 reopened this Nov 20, 2020
@campb303
Copy link
Collaborator Author

Several improvements were made to the look and performance of the QueueSelector this week:

Look

  • The helper text has been update to reflect the ability to either click or start typing to select a queue.
  • A loading indicator has been added to the right side of the QueueSelector to show motion and indicate that something is happening while the rest of the page is not changing.
  • A label have been added to the element to indicate explicitly what it is.
  • The QueueSelector is now an outlined text field sharing behavior between other textfields for simplicity.
  • Various spacing and sizing changed were made to keep the QueueSelector from awkwardly changing sizes when having content added or removed.

Behavior

  • API requests are no longer made after every selection, instead they are made based on the values selected when the QueueSelector is closed for performance improvements and to avoid costly page reloads.
  • Queue counts are refreshed every time the QueueSelector is opened for the most up to date info.
  • The field now autofocuses on page load as it is likely the first control to be used. This also makes keyboard navigation easier.
  • Text values are no longer autocompleted to avoid partial inputs that don't match available values.

Before
Old Queue Selector

After
New Queue Selector

@campb303
Copy link
Collaborator Author

This PR was accepted changing the closeIcon prop to clearIcon. This PR also closed the related issue.

As part of this conversation, I was asked to comment on the MUI v5 RFC re: component overriding here. Need to check with leads about whether I can spend time on this kind of thing.

@campb303 campb303 added the high-priority Needs immediate extra focus label Nov 25, 2020
@campb303 campb303 removed the high-priority Needs immediate extra focus label May 19, 2021
Sign in to join this conversation on GitHub.
Labels
feature-request Request for functionality that has not already been implemented
Projects
None yet
Development

No branches or pull requests

1 participant