Skip to content
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

refactor(v2): various dropdown improvements #3585

Merged
merged 8 commits into from
Oct 16, 2020
Merged

Conversation

lex111
Copy link
Contributor

@lex111 lex111 commented Oct 14, 2020

Motivation

image

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

Preview.

Related PRs

(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)

@lex111 lex111 added the pr: polish This PR adds a very minor behavior improvement that users will enjoy. label Oct 14, 2020
@lex111 lex111 requested a review from slorber as a code owner October 14, 2020 12:56
@facebook-github-bot facebook-github-bot added the CLA Signed Signed Facebook CLA label Oct 14, 2020
setShowDropdown(false);

const nextNavbarItem = (dropdownRef.current as HTMLElement)
.nextElementSibling;

if (nextNavbarItem) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wonder if it is possible to shorten this code down to one-line?

 const nextNavbarItem = (dropdownRef.current as HTMLElement).nextElementSibling;

if (nextNavbarItem) {
  (nextNavbarItem as HTMLElement).focus();
}

I have tried using optional chaining, but I ran into the type error.
Any clue? @slorber

Copy link
Collaborator

Choose a reason for hiding this comment

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

Afaik it's annoying but we can't do anything about the types not being the proper ones.

The shortest is probably:

((dropDownRef.current as HTMLElement)
                    ?.nextElementSibling as HTMLElement)?.focus();

Not much better

@docusaurus-bot
Copy link
Contributor

docusaurus-bot commented Oct 14, 2020

Deploy preview for docusaurus-2 ready!

Built with commit 4e1f5b7

https://deploy-preview-3585--docusaurus-2.netlify.app

Copy link
Collaborator

@slorber slorber left a comment

Choose a reason for hiding this comment

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

Maybe try "./" for the PWA? (I'd rather manage this in a separate PR as we can't know if it breaks the PWA until the preview is deployed).

  • some inline comments

document.removeEventListener('mousedown', handleClickOutside);
document.removeEventListener('touchstart', handleClickOutside);
};
}, [dropdownRef]);
Copy link
Collaborator

Choose a reason for hiding this comment

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

don't like much making the code a bit more complex, but as it should reduce a bit the bundle size, let's do this.

setShowDropdown(false);

const nextNavbarItem = (dropdownRef.current as HTMLElement)
.nextElementSibling;

if (nextNavbarItem) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Afaik it's annoying but we can't do anything about the types not being the proper ones.

The shortest is probably:

((dropDownRef.current as HTMLElement)
                    ?.nextElementSibling as HTMLElement)?.focus();

Not much better

@@ -290,6 +290,7 @@ declare module '@theme/NavbarItem/DefaultNavbarItem' {
activeClassName?: string;
prependBaseUrlToHref?: string;
isActive?: () => boolean;
position?: string;
Copy link
Collaborator

@slorber slorber Oct 15, 2020

Choose a reason for hiding this comment

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

I don't think this is an improvement. We shouldn't declare a useless props to filter it out deep in the tree.
Instead we should ensure to never pass a position props to the NavLink in the first place, which is what the previous code did

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah agree, apparently the problem lies here

// TODO we should probably create a custom navbar item type "dropdown"

But so far I don't really understand how to do this with Joi.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in d1b43ca
But not sure if this is correct.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

9:47:03 PM: Error: "navbar.items[4].items[0]" contains link reference "ref:local:baseNavbarItem" which is outside of schema boundaries

Hm, locally it works for me...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in 5b34e75
I don't know for sure it's all correct (ha ha).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the past we had some issues on some releases because we had too strict validation rules, and some users wanted to pass additional attributes like target=_blank , data attributes or other fancy props that a link should accept, so we should rather ensure it's still possible after this refactor.

I understand your concern, but after that change everything seems to work as before. The GitHub link has a custom attr ʻaria-label`. I just created a base type for the link, which then extends by the navbar item, and is also used for dropdown (child) links.

Alright, I'll try to write tests. Could you please help me describe which navbar cases need to be tested? It looks like we don't have enough tests for validation navbar.

Copy link
Collaborator

@slorber slorber Oct 16, 2020

Choose a reason for hiding this comment

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

Basically we should forward additional item props to the Link, so that user can pass whatever he wants a link support (target, data attributes,...). So in the end you add objectSchema.unknown() and ensure that passing such attributes are accepted.

I don't think we can easily validate all additional props that a Link can accept, so not sure there's a better option than unknown()

I don't find a good issue for those nav items validation regarding custom attributes, but here are various bug reports regarding validation that we had:

Copy link
Contributor 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 we can easily validate all additional props that a Link can accept, so not sure there's a better option than unknown()

I think using unknown() is a great option, the gist of my change is that we are not setting a default value for position and hence don't pass this prop to the component. I don’t understand yet what could be broken, but will write more tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tried testing all navbar items use cases in 4e1f5b7
Do you think it's right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

that looks safe thanks, let's merge

@slorber slorber merged commit 8f5c632 into master Oct 16, 2020
@lex111 lex111 deleted the lex111/dropdown-imp branch October 16, 2020 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Signed Facebook CLA pr: polish This PR adds a very minor behavior improvement that users will enjoy.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants