Skip to content
This repository has been archived by the owner on Dec 18, 2024. It is now read-only.

refactor(toc): use cdkScrollable for scrolling, remove unnecessary inputs #321

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

willshowell
Copy link
Contributor

  • Combine duplicated logic
  • (try to) increase readability
  • Use cdkScrollable for subscribing to scroll events
  • Use _activeLinkIndex to ensure only a single link is active at a time (removes active from link interface)
  • Remove input decorator from links
  • Fix bug where navigating to a page with a fragment would not scroll the header into view until clicking on the link

Note: this still does not work for toc on the guides pages. I thought scrolling would be on the window and therefore be picked up by the scroll dispatcher, but that does not seem to be the case.

cc @jelbourn

if (target) {
target.scrollIntoView();
}
contentReady(): void {
Copy link
Member

Choose a reason for hiding this comment

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

I'd rather name this method for what it does rather than when it's called

}
/** Find the target from the url fragment and scroll it into view. */
private scrollFragmentIntoView(): void {
this._ngZone.runTask(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Why does this need to enter the zone if it's only updating the scroll position?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops that was leftover from debugging something else. Removed.

this._ngZone.runTask(() => {
const target = document.getElementById(this._urlFragment);
if (target) {
// scrollIntoView may require next macrotask if target has just been loaded
Copy link
Member

Choose a reason for hiding this comment

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

I don't quite follow why this is necessary; the document-viewer knows exactly when the content is loaded and in the DOM

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Without it, scroll position would always end up at the top of the page (can be seen here).

However I now recall that there was some other component that manually updates the scroll position. I'll try to track down any sort of race condition occurring there.

Copy link
Contributor Author

@willshowell willshowell Nov 13, 2017

Choose a reason for hiding this comment

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

Yeah it's conflicting with the navigation focus directive,

ngOnInit() {
clearTimeout(lastTimeoutId);
// 100ms timeout is used to allow the page to settle before moving focus for screen readers.
lastTimeoutId = setTimeout(() => this.el.nativeElement.focus(), 100);
}

EDIT: actually not so sure

EDIT 2: It was the component overview doing the auto focus, not the navigation focus directive

@willshowell
Copy link
Contributor Author

@jelbourn ready for another review. The component overview and component api components were autofocusing the visually hidden element at the top after 100ms. I've changed them to wait until the content has loaded, but before the TOC scrolls the correct header into view.

Would it be better for a11y to place focus on the header link when the fragment does exist?

@jelbourn
Copy link
Member

@willshowell Yeah, if there is a fragment then the autofocus should be on the header for that fragment. I think that was just an oversight when doing the autofocus. Would you be interested in addressing that in this PR?

@willshowell
Copy link
Contributor Author

@jelbourn Ugh I thought I'd be able to easily, but I'm hitting some strange behavior where focus() is noop on the header-link unless setTimeout is used. I'd like to defer that to a later PR.

@jelbourn jelbourn requested a review from amcdnl December 8, 2017 00:04
@jelbourn
Copy link
Member

jelbourn commented Dec 8, 2017

@amcdnl can you review?

Copy link
Contributor

@amcdnl amcdnl left a comment

Choose a reason for hiding this comment

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

Looks good overall, just one suggestion for lettables.

import {Subject} from 'rxjs/Subject';
import 'rxjs/add/operator/filter';
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets use Rx Lettables here. I have a PR to transform the rest of them in the app.

@willshowell
Copy link
Contributor Author

@jelbourn @amcdnl rebased and comments addressed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants