Skip to content

feat(list-key-manager): accept item references in setActiveItem #10029

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
Mar 1, 2018

Conversation

crisbeto
Copy link
Member

  • Adds an overload to setActiveItem to allow for an item to be set as active, rather than its index. This avoids awkward conversions in certain cases (see the chips and select changes).
  • Deprecates the updateActiveItemIndex method in favor of updateActiveItem which accepts both an index and an item.
  • Fixes the active item not being updated when it is set via updateActiveItemIndex.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Feb 19, 2018
@crisbeto crisbeto force-pushed the list-key-manager-set-item branch 2 times, most recently from 01f08ef to 8234653 Compare February 20, 2018 17:07
* previously active item.
* @param item Item to be set as active.
*/
setActiveItem(item: T): void;
Copy link
Member

Choose a reason for hiding this comment

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

Technically T could be number. It would avoid the ambiguity if we just kept the separate methods (setActiveItem and setActiveItemIndex)

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think so. The _items that are passed in through the constructor are a QueryList which can't contain numbers.

Copy link
Member

Choose a reason for hiding this comment

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

Is there ever a time when a component would want to use one or the other in a single call? Still seems like it would be more explicit to have both methods with index vs. item behaviors.

Copy link
Member Author

Choose a reason for hiding this comment

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

It would be more explicit, but it adds a couple of extra methods to the API that do more or less the same. I don't think there's a case where a component would want to use both of them in the same call.

Copy link
Member

Choose a reason for hiding this comment

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

Ack, I don't feel that strongly. My only other comment would be that the implemention method should be item: T|number

Copy link
Member Author

Choose a reason for hiding this comment

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

That's what I was going for initially, but then TS seems to have a hard time figuring out the type when we pass the item to updateActiveItem. There were also some issues when trying to assign the active item inside the derived classes. I went with any since the implementation method signature won't show up in the type info anyway.

* Adds an overload to `setActiveItem` to allow for an item to be set as active, rather than its index. This avoids awkward conversions in certain cases (see the chips and select changes).
* Deprecates the `updateActiveItemIndex` method in favor of `updateActiveItem` which accepts both an index and an item.
* Fixes the active item not being updated when it is set via `updateActiveItemIndex`.
@crisbeto crisbeto force-pushed the list-key-manager-set-item branch from 8234653 to dfa2b7a Compare February 24, 2018 08:01
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 pr: lgtm action: merge The PR is ready for merge by the caretaker and removed pr: needs review labels Feb 26, 2018
@crisbeto crisbeto added the target: minor This PR is targeted for the next minor release label Feb 26, 2018
@tinayuangao tinayuangao merged commit 92ed9c8 into angular:master Mar 1, 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.

4 participants