-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Components: refactor NavigationItem
to pass exhaustive-deps
#41639
Conversation
66be9aa
to
47f5650
Compare
Size Change: 0 B Total Size: 1.25 MB ℹ️ View Unchanged
|
47f5650
to
ad95e3b
Compare
|
||
export const useNavigationTreeNodes = () => { | ||
const [ nodes, setNodes ] = useState( {} ); | ||
|
||
const getNode = ( key ) => nodes[ key ]; | ||
|
||
const addNode = ( key, value ) => { | ||
const addNode = useCallback( ( key, value ) => { |
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.
Hmm, I feel the same way I felt about the useCallback
s in #41749 (comment), where it moves the responsibility away from the module that should be responsible for preventing breakage, which is useNavigationTreeItem
itself. These Navigation modules look pretty complex, and it would be hard to know that referential stability in useNavigationTreeNodes
could subtly break a useEffect
somewhere far from it.
}, [ | ||
activeMenu, | ||
search, | ||
addItem, | ||
removeItem, | ||
props, | ||
group, | ||
itemId, | ||
menu, | ||
] ); |
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.
Unfortunately there weren't any unit tests for this, but I noticed that search mode is now broken. (Not that trunk
is in great shape — the input field CSS is somehow borked 😅 But the functionality is there.)
Given that Navigation
is kind of deprecated in favor of Navigator
(if I understood correctly), I think it would be fine to stuff everything else in a ref
object or eslint-disable
this one if it gets gnarly. Unless we're going to do a deep clean rewrite of this chunk of code, I think it might actually be useful to retain some indication of the original author's intent (i.e. only fire the effect when activeMenu
or search
changes).
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.
Unfortunately there weren't any unit tests for this, but I noticed that search mode is now broken. (Not that trunk is in great shape — the input field CSS is somehow borked 😅 But the functionality is there.)
I see the CSS issues for sure, depending on the fate of Navigation
, might be worth a follow up PR. Are there other/new issues in Search that I missed? Or just that special input CSS? 😆
For the rest - that all makes sense, thanks for pointing out where the responsibility should lie. For now, I'll update this PR to disable the rule for this particular component, linking back here for context if it's ever needed in the future!
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.
Are there other/new issues in Search that I missed?
The only two that I noticed was the infinite update loop that was happening pre-revert (b2a0fc7), and the CSS issue (pre-existing).
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.
Gotcha, thank you!
8590f54
to
798f3fe
Compare
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.
🚀
What?
Updates the
NavigationItem
component ignore theexhaustive-deps
eslint rule for now.Navigation
looks like it might need a deeper dive refactor to easily satisfyexhuastive-deps
, and we may actually prefer usingNavigator
instead. For now, we'll disable warnings for this component, and can revisit the eslint rule if/when this component gets more attention in the future.Why?
Part of the effort in #41166 to apply
exhuastive-deps
to the Components packageHow?
TheuseEffect
inuseNavigationTreeItem.js
was missing most of its dependencies. Most (props
,group
,itemId
, andmenu
) were addable without introducing unexpected behavior.addItem
andremoveItem
however were being redeclared on each render before being read from context. Wrapping each inuseCallback
allows for more stable references, preventing additional re-renders.Testing Instructions
npx eslint --rule 'react-hooks/exhaustive-deps: warn' packages/components/src/navigation/item
navigation
unit tests still passNavigation
component stories and/or docs still work as expected