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

CHK-134: Drop-down field style of Location Search autocomplete component #21

Merged
merged 32 commits into from
Jul 31, 2020

Conversation

wdsrocha
Copy link
Contributor

@wdsrocha wdsrocha commented Jul 16, 2020

What problem is this solving?

Continuation of #17 and #20, implements the styling part of the following component.

image

How should this be manually tested?

  1. Add any product to cart;
  2. Go to shipping step, it will be the first component displayed (it's placed there just for convenience).
  3. Compare to Figma, play around, etc.

Usage example

import GoogleLogo from './../assets/powered_by_google.png'

// ...

<LocationSearch
  renderEngineLogo={() => (
    <img className="h1" src={GoogleLogo} alt="Powered by Google" />
  )}
/>

@vtex-io-ci-cd
Copy link

vtex-io-ci-cd bot commented Jul 16, 2020

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

  • Patch (backwards-compatible bug fixes)

  • Minor (backwards-compatible functionality)

  • Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

  • No thanks, I would rather do it manually 😞

@vtex-io-docs-bot
Copy link

vtex-io-docs-bot bot commented Jul 16, 2020

Beep boop 🤖

I noticed you didn't make any changes at the docs/ folder

  • There's nothing new to document 🤔
  • I'll do it later 😞

In order to keep track, I'll create an issue if you decide now is not a good time

  • I just updated 🎉🎉

@wdsrocha wdsrocha force-pushed the feature/combobox-style branch from 088d57b to 1b57356 Compare July 16, 2020 21:59
@wdsrocha wdsrocha force-pushed the feature/combobox-style branch from 9877269 to 1e11bbe Compare July 21, 2020 19:15
wdsrocha added 3 commits July 21, 2020 16:35
Notes:
- there is no #DBE9FD as common bg color on Tachyons
- used bg-action-secondary for aria-selected (#EEF3F7) instead
react/LocationSearch.tsx Outdated Show resolved Hide resolved
react/addresses.tsx Outdated Show resolved Hide resolved
@wdsrocha wdsrocha marked this pull request as ready for review July 22, 2020 15:20
@wdsrocha wdsrocha requested a review from a team as a code owner July 22, 2020 15:20
@wdsrocha wdsrocha requested review from darlenedms, jeffersontuc and lucasecdb and removed request for a team July 22, 2020 15:20
react/LocationSearch.tsx Outdated Show resolved Hide resolved
react/LocationSearch.tsx Outdated Show resolved Hide resolved
react/LocationSearch.tsx Show resolved Hide resolved
react/LocationSearch.tsx Outdated Show resolved Hide resolved
react/components/Combobox.tsx Outdated Show resolved Hide resolved
const { mainText } = suggestion
const { offset, size } = suggestion.mainTextMatchInterval
return (
<div className="truncate c-muted-2">
Copy link
Contributor Author

@wdsrocha wdsrocha Jul 28, 2020

Choose a reason for hiding this comment

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

When the text inside an Option is too big, it will truncate with an ellipsis, but there is a problem: the mainText (street name) is black and the secondaryText (city and state name) is gray, which would require the ellipsis color to be dynamic, depending on which part have overflowed.

Doing this at implementation level is quite painful and don't seems to bring too much value (big street names aren't very common, I guess), so I've opted to always display the ellipsis with a gray color. Is that okay? @davicosta99 @augustocb

Example of fake big street name with the grey colored ellipsis:

Choose a reason for hiding this comment

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

I think it's fine, Wesley, thanks for the concern. Appreciate the level of care 😉

Comment on lines 9 to 11
.option:active {
background-color: #d2defc
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@davicosta99, while addressing the following issue

When a suggestion is selected (on:active) it should blink in the on-action color token (#D2DEFC) for 50ms before closing.

I found out that this color does not exist on VTEX Tachyons spec, so I’ve added it directly here.

Also, how do I know if it takes 50ms during the blink? Is that the standard behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same goes for #c4c4c4 on Place Icon and #2e2e2e on Warning Icon, but I used the closest "c-muted-x" for them:

  • #c4c4c4 -> #cacbcc (c-muted-3)
  • #2e2e2e -> #727273 (c-muted-1)

Copy link

@davicostalf davicostalf Jul 29, 2020

Choose a reason for hiding this comment

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

Currently we have these tokens, that basically reuse the hover color.

.active-bg-action-secondary:active { background-color: #dbe9fd; }
.active-b--action-secondary:active { border-color: #dbe9fd; }

Can you change them to #D2DEFC? This change was made in Figma but never implemented.

Regarding the 50ms, I thought this was something that needed to be defined. Right now is perfect already.

Sorry for the mistake on the grays, my bad. Thanks for using the right tokens 😉

@wdsrocha
Copy link
Contributor Author

@davicosta99

The max-width for the field is not the same as in the Figma file.

This task/PR only addresses the LocationSearch component itself, so I'll worry with the resize later on, when integrating with the NewFormAddress component inside the shipping step. But thanks for pointing that out, I ended up finding a bug related to that!

I'm not able to test on my phone because after submitting the profile step I get this error

I don't know why this is happening to you, just tried on my phone and it seems to be working fine. Could you try again, starting from the cart step?

@wdsrocha wdsrocha requested a review from augustocb July 28, 2020 19:18
Comment on lines 15 to 38
interface Interval {
offset: number
size: number
}

const MAX_DROPDOWN_ADDRESSES = 6
export interface Suggestion {
description: string
mainText: string
mainTextMatchInterval: Interval
secondaryText: string
}

// This function will be replaced in the future, after integrating the
// component with GraphQL queries.
const getAddresses = (searchTerm: string) => {
return mockedAddresses
.filter((address: string) =>
address.toLocaleLowerCase().includes(searchTerm.toLocaleLowerCase())
)
.slice(0, MAX_DROPDOWN_ADDRESSES)
const renderSuggestionText = (suggestion: Suggestion) => {
const { mainText } = suggestion
const { offset, size } = suggestion.mainTextMatchInterval
return (
<div className="truncate c-muted-2">
<span className="c-on-base">{mainText.substr(0, offset)}</span>
<span className="c-on-base b">{mainText.substr(offset, size)}</span>
<span className="c-on-base">{mainText.substr(size + offset)}</span>
<span>{` ${suggestion.secondaryText}`}</span>
</div>
)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

About the full address being displayed

In order to handle this, I’ve opted for implementing something similar to Google autocomplete (see AutocompletePrediction Interface). When the user inputs the text "bri" into the input box, an answer like this will be returned:

[
  {
    "description": "Cambridge, Rockford, Illinois",
    "mainText": "Cambridge",
    "secondaryText": "Rockford, Illinois",
    "mainTextMatchInterval": {
      "offset": 3,
      "size": 3
    }
  },
  {
    "description": "Briar Crest, Hagerstown, Maryland",
    "mainText": "Briar Crest",
    "secondaryText": "Hagerstown, Maryland",
    "mainTextMatchInterval": {
      "offset": 0,
      "size": 3
    }
  }
]

Which will be converted to (just the first one, for simplicity):

<div className="truncate c-muted-2">
  <span className="c-on-base">Cam</span>
  <span className="c-on-base b">bri</span>
  <span className="c-on-base">dge</span>
  <span>Rockford, Illinois</span>
</div>

And displayed like:

Explanation of the fields:

  • description: the text that will go to the input box when the user selects it
  • mainText: probably the street name (along with the number, maybe?)
  • secondaryText: larger administrative regions like city, state and country
  • mainTextMatchInterval: used to highlight the part of the mainText that matched the user input. This can be improved to hold multiple matches and/or include the secondaryText, but for now, I think imitating the Google behavior might be sufficient (which is just like that).

This isn't very flexible, but looks sufficient to me. Opinions?

Copy link

@davicostalf davicostalf Jul 29, 2020

Choose a reason for hiding this comment

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

Seems enough for me as well. I also don't believe we should include the secondaryText in the mainTextMatchInterval or multiple matches.

@wdsrocha wdsrocha requested a review from lucasecdb July 28, 2020 19:36
Copy link

@davicostalf davicostalf left a comment

Choose a reason for hiding this comment

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

Besides including the color in our Tachyons like I've mentioned above, the only other issue I found was this:
Screen-Recording-2020-07-29-at-16 34 12
It seems like no result is found when the secondary text is included in the search term. Is this happening because of the mocked data or does something need to be corrected?

Comment on lines 32 to 34
<span className="c-on-base">{mainText.substr(0, offset)}</span>
<span className="c-on-base b">{mainText.substr(offset, size)}</span>
<span className="c-on-base">{mainText.substr(size + offset)}</span>
Copy link
Contributor

Choose a reason for hiding this comment

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

can we opt in to a simpler markup? like the following

Suggested change
<span className="c-on-base">{mainText.substr(0, offset)}</span>
<span className="c-on-base b">{mainText.substr(offset, size)}</span>
<span className="c-on-base">{mainText.substr(size + offset)}</span>
<span className="c-on-base">
{mainText.substr(0, offset)}
<span className="b">{mainText.substr(offset, size)}</span>
{mainText.substr(size + offset)}
</span>

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 think so, it looks better indeed. I was just worried that this wouldn't be good at a semantic level, but thinking again, I guess there is nothing wrong with a nested span.

Copy link
Contributor

Choose a reason for hiding this comment

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

yep, it's an inline element inside another inline element, so I think we should be fine

@wdsrocha
Copy link
Contributor Author

It seems like no result is found when the secondary text is included in the search term. Is this happening because of the mocked data or does something need to be corrected?

@davicosta99 as commented here, the current search algorithm is pretty naive and for testing purposes only. But I'll keep an eye on caching, as I suppose it does not make too much sense to re-do a request for this kind of search that you have pointed out.

Copy link
Contributor

@lucasecdb lucasecdb left a comment

Choose a reason for hiding this comment

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

LGTM, left a nitpick

<span className="b">{mainText.substr(offset, size)}</span>
{mainText.substr(size + offset)}
</span>
<span>{` ${suggestion.secondaryText}`}</span>
Copy link
Contributor

Choose a reason for hiding this comment

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

sorry I missed this in the last review, but it's just a nitpick

Suggested change
<span>{` ${suggestion.secondaryText}`}</span>
{' '}<span>{suggestion.secondaryText}</span>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, but the formatter sent the whitespace to the line above.

@@ -55,7 +55,7 @@ export const ComboboxOption: React.FC<ReachComboboxOptionProps & {
className={classNames(
className,
styles.option,
'flex items-center pointer bg-action-secondary pv3 ph5 hover-bg-action-secondary'
'flex items-center pv3 ph5 pointer bg-action-secondary hover-bg-action-secondary active-bg-action-secondary'
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now this is "incorrect", but as soon as Styleguide bumps the Tachyons version, I'll open a PR bumping the Styleguide version here and it will have the expected color.

Copy link
Contributor

Choose a reason for hiding this comment

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

you don't actually need to bump styleguide here after deploying the new version with vtex-tachyons updated, because the IO infra will automatically bump the styleguide version on the account itself when it is published.

@wdsrocha wdsrocha requested a review from davicostalf July 31, 2020 13:08
Copy link

@davicostalf davicostalf left a comment

Choose a reason for hiding this comment

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

LGTM

@wdsrocha wdsrocha changed the title CHK-134: Drop-down field style of Location Search autocomplete component Refactor and style Location Search autocomplete Jul 31, 2020
@wdsrocha wdsrocha merged commit e184d06 into feature/location-search Jul 31, 2020
@wdsrocha wdsrocha deleted the feature/combobox-style branch July 31, 2020 22:12
@wdsrocha wdsrocha changed the title Refactor and style Location Search autocomplete CHK-134: Drop-down field style of Location Search autocomplete component Jul 31, 2020
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.

5 participants