Navigation component: Fix item handling onClick twice #33286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +16 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
jeyip
reviewed
Jul 13, 2021
jeyip
reviewed
Jul 13, 2021
| @@ -63,14 +63,15 @@ export default function NavigationItem( props ) { | |||
| onClick( event ); | |||
| }; | |||
| const icon = isRTL() ? chevronLeft : chevronRight; | |||
| const baseProps = isText | |||
| const baseProps = children ? props : { ...props, onClick: undefined }; | |||
There was a problem hiding this comment.
I might be missing something, but if isText is false and children is true, couldn't we still have 2 onClick handlers registered?
There was a problem hiding this comment.
I don't think so 🤔 We don't apply the props on the children automatically. So in this case NavigationItemBase will get an onClick˛handler but nothing else. You can still put an onClick handler on your children in the userland code. But that would mean you are using the component wrong.
Correct way is to add your onClick to the NavigationItem:
<NavigationItem onClick={() => alert('Hello')}>
<div>There is only one event click handler</div>
</NavigationItem>Wrong way
<NavigationItem onClick={() => alert('Hello')}>
<div onClick={() => alert('Hello children!')}>There is only one event click handler</div>
</NavigationItem>Note, when we have children then the itemProps is not used at all.
There was a problem hiding this comment.
Note, when we have children then the itemProps is not used at all
Ahhh I think this is what's confusing me. Why use isText at all if we can infer component state from the presence or absence of children?
There was a problem hiding this comment.
We need to make sure ItemUI is acting as a text in case of isText, otherwise we turn it into a button.
isText = true = We pass rest props, so it's up to the user to add extra props
isText = false = We default to a clickable navigation button
There was a problem hiding this comment.
Oh I see what's happening now 🤦 . I'm tracking. Thanks for the explanation @david-szabo97!
jeyip
approved these changes
Jul 15, 2021
0101d9c to
142c6df
Compare
gwwar
pushed a commit
that referenced
this pull request
Jul 19, 2021
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Both
NavigationItemBaseandItemUIregistered anonClickevent listener. This PR tries to ensure that it is only registered once on the right component. (ItemUI)When
childrenis specified then we leave the choice of addingonClickto theNavigationItemBaseto the consumer. In other case, we use the defaultItemUIcomponent which means we need to remove theonClickfrom the props passed toNavigationItemBaseto avoid double event handling.How has this been tested?
core/edit-siteinstance)Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.jsfiles for terms that need renaming or removal).