-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
feat(tab-bar): Add focusOnActivate flag #3748
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3748 +/- ##
==========================================
+ Coverage 98.47% 98.51% +0.04%
==========================================
Files 120 120
Lines 5232 5239 +7
Branches 657 658 +1
==========================================
+ Hits 5152 5161 +9
+ Misses 80 78 -2
Continue to review full report at Codecov.
|
All 557 screenshot tests passed for commit 8dc5c95 vs. |
@@ -102,7 +110,9 @@ class MDCTabFoundation extends MDCFoundation { | |||
this.adapter_.setAttr(strings.ARIA_SELECTED, 'true'); | |||
this.adapter_.setAttr(strings.TABINDEX, '0'); | |||
this.adapter_.activateIndicator(previousIndicatorClientRect); | |||
this.adapter_.focus(); | |||
if (this.focusOnActivate_) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to make this a parameter for the activate
function that can be passed by the TabBar
. Then, focusOnActivate
won't need to be stored in each Tab
instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So TabBar
would pass it's value for focusOnActivate
to a Tab
via the activate
method. I realize this makes more changes to the Tab
foundation interface. If you're trying to prevent breaking changes, we can roll with the existing solution. Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your idea is the first idea I had, but I thought against it for a couple of reasons:
- It would make the
activate
API more awkward, given that it already has an optionalClientRect
parameter - Semantically, it seems unlikely that you'd want to call this with different values across the same instance's lifetime; you'd probably just want to set the behavior once and roll with it
It wouldn't necessarily be a breaking change that way, since it could also be optional with a default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True true, those are all good points.
All 557 screenshot tests passed for commit e5111ec vs. |
Fixes #3585.
This also adds docs and tests I apparently missed for
useAutomaticActivation
, and removes an unused property back from before event registration was moved to the components.