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

Update Navigation & Search #794

Merged
merged 34 commits into from
Mar 17, 2020

Conversation

carlfairclough
Copy link
Contributor

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

  • Removed navigation duplication from the Outline
  • No separate sidebar component
  • All navigation display is managed within CSS, with visibility props being managed via CSS
  • Search edge states catered for
    • Blank
    • No results

Related Issue

#764 #755

Screenshots (if appropriate):

Desktop

Nav Items

image
image

Search

Results
image
image

Blank States
image
image
image

Mobile

image
image
image
image
image
image

@carlfairclough carlfairclough changed the title Update Navigation & Search [WIP] Update Navigation & Search Mar 4, 2020
@carlfairclough carlfairclough changed the title [WIP] Update Navigation & Search Update Navigation & Search Mar 4, 2020
@carlfairclough
Copy link
Contributor Author

carlfairclough commented Mar 4, 2020

@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 NavLink.vue component.

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

Copy link
Member

@samajammin samajammin left a 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.

docs/.vuepress/theme/Layout.vue Outdated Show resolved Hide resolved
docs/.vuepress/theme/components/NavLinks.vue Show resolved Hide resolved
docs/.vuepress/theme/components/Navigation.vue Outdated Show resolved Hide resolved
docs/.vuepress/theme/Layout.vue Show resolved Hide resolved
docs/.vuepress/theme/Layout.vue Outdated Show resolved Hide resolved
isSearchFocused: function() {
// watch it
this.isSearchFocused &&
document.getElementById('main-search-field').focus()
Copy link
Member

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 }"

Copy link
Contributor Author

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:

  1. User taps "search" on mobile
  2. 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">
Copy link
Member

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.

Copy link
Contributor Author

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) {
Copy link
Member

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.

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'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

Copy link
Member

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.

Copy link
Contributor Author

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) {
Copy link
Member

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.

docs/.vuepress/theme/components/SearchBox.vue Outdated Show resolved Hide resolved
@samajammin
Copy link
Member

Another styling note - let's ensure the search doesn't overlap the sidebar (i.e. keep the current functionality).

Current:
Image 2020-03-05 at 7 49 57 AM

Your PR:
Image 2020-03-05 at 7 49 51 AM

@samajammin
Copy link
Member

A couple style notes on the desktop nav.

  1. The nav icon is now too small & no longer center aligned
  2. The links feel awkwardly far apart

Style guide:
Image 2020-03-05 at 7 52 43 AM

Your PR:
Image 2020-03-05 at 7 53 58 AM

@samajammin
Copy link
Member

@carlfairclough what is the Outline you're referring to in the PR description?

@carlfairclough
Copy link
Contributor Author

Another styling note - let's ensure the search doesn't overlap the sidebar (i.e. keep the current functionality).

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 @blur function is removed, but then escaping the view becomes difficult (either detect a click outside the element, which would introduce complexity or a slight restructure of the search which matches the dropdown, relying on :focus-within with CSS. I think :focus-within is the best option cause we can then remove some of the JS (i.e. isSearchFocused)

@carlfairclough
Copy link
Contributor Author

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

@carlfairclough
Copy link
Contributor Author

carlfairclough commented Mar 13, 2020

I've been testing the search in Safari (desktop) and come across an issue where blur prevents the @click, @mousedown, @mouseup events from firing, whether that's on the links themselves (@blur) or the wrapper (@focusout). I'm at a loss as to the cause here, and every solution seems to surface an issue in behavior (e.g. focus not firing).

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.

Copy link
Member

@samajammin samajammin left a 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) {
Copy link
Member

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"
Copy link
Member

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.

@samajammin
Copy link
Member

@carlfairclough approved! I'll merge this after you rebase against the latest dev branch. Holler if you want some quick assistance on that.

@samajammin
Copy link
Member

samajammin commented Mar 15, 2020

@carlfairclough - regarding your comment:

I've been testing the search in Safari (desktop) and come across an issue where blur prevents the @click, @mousedown, @mouseup events from firing, whether that's on the links themselves (@blur) or the wrapper (@focusout). I'm at a loss as to the cause here, and every solution seems to surface an issue in behavior (e.g. focus not firing).

So what's the impact from the perspective of a user here?

Edit

Oh, 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

Copy link
Member

@samajammin samajammin left a 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.

@carlfairclough
Copy link
Contributor Author

I think we're good to go unless there are any blunders @samajammin

Copy link
Member

@samajammin samajammin left a 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):

  1. Navigating search results with my keyboard should highlight the selected/focused option
  2. Hitting 'enter' key to navigate to my selection should close the search

Once those are fixed I think we're good to go!

@carlfairclough
Copy link
Contributor Author

@samajammin resolved the Safari issue & can tab (tab key) through search results

@samajammin
Copy link
Member

@carlfairclough awesome!!! Please resolve the merge conflicts & I'll work to get this merged ASAP.

Copy link
Member

@samajammin samajammin left a comment

Choose a reason for hiding this comment

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

Bravo 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants