-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Update Navigation & Search #794
Update Navigation & Search #794
Conversation
@samajammin here's a draft PR on this. It's not ready to be merged IMO because the way nav links are being styled is pretty messy and should be done inside the I'm pausing here because it's a huge change already & I would appreciate review to catch any glaring errors before I go and make that CSS manageable. I'm in particular looking for attention around how I'm managing properties/data with $emit |
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.
Nice work! Overall this looks great. Left a bunch of comments on ways I think this can be cleaned up. Let me know if you have questions.
isSearchFocused: function() { | ||
// watch it | ||
this.isSearchFocused && | ||
document.getElementById('main-search-field').focus() |
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.
Could we solve this with CSS instead? E.g. adding a conditional class :class="{ focused: isSearchFocused }"
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.
This isn't a css thing, this targeting the input field:
- User taps "search" on mobile
- Search opens, with the input focused and as a result their keyboard opens.
I've had to switch to a display: none
toggle for the search, which introduces issues with this anyway as it prevents the field from being focused. As a result I've stripped all of this out.
On a related note, something like :class="{ focused: isSearchFocused }"
is now being used. The css focus-within
selector isn't incredibly well supported so JS is handling this again (without significant changes):
searchClasses() {
return {
'search-box': true,
'search-hidden': !this.isSearchVisible,
'focus-within': this.focused
}
},
<icon name="search" class="icon-search-field" /> | ||
</div> | ||
|
||
<div v-if="blankState && isSearchFocused" class="blank-state"> |
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.
Should this only display if search is focused? Seems we could display this whether or not the search input is focused.
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.
This was a desktop-first approach and has been changed to be hidden with CSS instead when the search isn't focused
@@ -35,35 +135,222 @@ export default { | |||
} | |||
}, | |||
methods: { | |||
isActive | |||
isActive, | |||
handleSearchToggle(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.
Similar to handleNavToggle
, I think this could be simplified to just toggle a boolean without passing a 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.
I'd prefer to keep this, it allows us to clear the search in certain scenarios i.e. when a link is clicked. imo it's much better to be explicit when there's a desired behaviour
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.
I don't follow - it allows us to clear the search in certain scenarios i.e. when a link is clicked
- where are we doing this? From what I understand this merely sets isSearchVisible
to true or false.
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.
Switched this out for the toggle like you mentioned — I honestly prefer being super explicit but I'll go with your judgement
handleSearchToggle(value) { | ||
this.isSearchVisible = value | ||
}, | ||
handleFocusToggle(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.
Similar to handleNavToggle
, I think this could be simplified to just toggle a boolean without passing a value.
@carlfairclough what is the |
I'm not sure I agree with this, i don't think this negatively impacts anything and is impacted by the icons/text to the right On the focus state & classes: I'm exploring this, it focuses/tabs fine with the |
I believe this is ready for merge @samajammin. I've addressed most of your comments & replied to the ones which I haven't actioned with explanation |
I've been testing the search in Safari (desktop) and come across an issue where blur prevents the The last resort would be to only show results when the input is focused (existing behaviour) but imo that is less than ideal, so any help would be massively appreciated. |
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.
A few minor simplifications I'd like to make but approving this as-is. Great work here! This is a excellent improvement 🔎 🎉
@@ -35,35 +135,222 @@ export default { | |||
} | |||
}, | |||
methods: { | |||
isActive | |||
isActive, | |||
handleSearchToggle(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.
I don't follow - it allows us to clear the search in certain scenarios i.e. when a link is clicked
- where are we doing this? From what I understand this merely sets isSearchVisible
to true or false.
<NavLinks | ||
:isDarkMode="isDarkMode" | ||
:isMobileNavVisible="isMobileNavVisible" | ||
:handleNavToggle="handleNavToggle" |
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.
Right but your passing handleNavToggle
to the NavLinks
component, which doesn't do anything with that prop. I removed this line locally & it doesn't seem to change any
functionality.
@carlfairclough approved! I'll merge this after you rebase against the latest |
@carlfairclough - regarding your comment:
So what's the impact from the perspective of a user here? EditOh, is this the issue where we've lost the styling on the focused search item? This is definitely a showstopper I forgot to mention. Here's an example - I arrow'd down & selected enter on the 2nd option but the UI gives no clues to this: https://share.getcloudapp.com/NQuZlzL9 |
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.
Per the comment above, we need to fix the focus styles when navigating search results with the keyboard before merging this.
I think we're good to go unless there are any blunders @samajammin |
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.
Getting close!
2 things I immediately notice when testing the search (see screen recording):
- Navigating search results with my keyboard should highlight the selected/focused option
- Hitting 'enter' key to navigate to my selection should close the search
Once those are fixed I think we're good to go!
@samajammin resolved the Safari issue & can tab (tab key) through search results |
@carlfairclough awesome!!! Please resolve the merge conflicts & I'll work to get this merged ASAP. |
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.
Bravo 👏
Updated navigation & search components
Description
A pretty in-depth update of navigation and search. Involves modal-style overlays and navigation within the menu sidebar. It also involves extras
Outline
Related Issue
#764 #755
Screenshots (if appropriate):
Desktop
Nav Items
Search
Results
Blank States
Mobile