Skip to content

feat(list-key-manager): add support for horizontal directions #9122

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 23, 2018

Conversation

crisbeto
Copy link
Member

Updates the ListKeyManager to add support for using ltr and rtl directions. This will allow us to switch over even more components to the key manager (e.g. chips, tabs, stepper) as well as support more use cases (e.g. moving selection with the left/right arrows on a closed select).

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Dec 25, 2017
* Configures the directions in which the user can move the selection.
* @param directions One or more directions that the user can move the selection in.
*/
withDirections(...directions: ListKeyManagerDirection[]): this {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of making this two method: withVerticalOrientation() and withHorizontalOrientation(dir)?

What did you have in mind for cases when it could have both turned on?

Copy link
Member Author

@crisbeto crisbeto Jan 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API-wise I'm fine with having separate methods, but it would make it slightly less convenient to deal with internally.

Regarding use cases, off the top of my head there are a couple:

  1. Based on the a11y guidelines, horizontal tabs navigate using left/right arrows, whereas vertical tabs (which we use for the stepper) use both left/right and up/down.
  2. Native select elements allow you to change the value when closed both by pressing the up/down arrows, as well as left/right.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm.........

My main reason or not liking everything in one method is that it lets users provide an invalid combination (even though it's caught). Another option would be to separate the orientation from the direction into separate methods, so you'd have something like

withOrientation(...orientations: Horizontal | Vertical) { }

withDirectionality(dir) { } // defaults to LTR

Updates the `ListKeyManager` to add support for using ltr and rtl directions. This will allow us to switch over even more components to the key manager (e.g. chips, tabs, stepper) as well as support more use cases (e.g. moving selection with the left/right arrows on a closed select).
@crisbeto crisbeto force-pushed the list-key-manager-directions branch from 2eeed02 to 179feb0 Compare January 13, 2018 12:52
@crisbeto
Copy link
Member Author

Reworked based on the feedback @jelbourn.

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added action: merge The PR is ready for merge by the caretaker target: minor This PR is targeted for the next minor release pr: lgtm and removed pr: needs review labels Jan 16, 2018
@jelbourn jelbourn merged commit ab02367 into angular:master Jan 23, 2018
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants