refactor(v2): various dropdown improvements #3585
Conversation
lex111
added
the
pr: polish
| setShowDropdown(false); | ||
|
|
||
| const nextNavbarItem = (dropdownRef.current as HTMLElement) | ||
| .nextElementSibling; | ||
|
|
||
| if (nextNavbarItem) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
Deploy preview for docusaurus-2 ready! Built with commit 4e1f5b7 |
| document.removeEventListener('mousedown', handleClickOutside); | ||
| document.removeEventListener('touchstart', handleClickOutside); | ||
| }; | ||
| }, [dropdownRef]); |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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; | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Yeah agree, apparently the problem lies here
But so far I don't really understand how to do this with Joi.
There was a problem hiding this comment.
Done in d1b43ca
But not sure if this is correct.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Fixed in 5b34e75
I don't know for sure it's all correct (ha ha).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Tried testing all navbar items use cases in 4e1f5b7
Do you think it's right?
There was a problem hiding this comment.
that looks safe thanks, let's merge
Motivation
use-onclickoutsidedep in favor of own realizationpositionfrom final markup (similar to fix(v2): remove invalid attr from mobile nav links #2765)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.)