-
Notifications
You must be signed in to change notification settings - Fork 4
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
Conversation
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:
And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.
|
Beep boop 🤖 I noticed you didn't make any changes at the
In order to keep track, I'll create an issue if you decide now is not a good time
|
088d57b
to
1b57356
Compare
9877269
to
1e11bbe
Compare
Notes: - there is no #DBE9FD as common bg color on Tachyons - used bg-action-secondary for aria-selected (#EEF3F7) instead
const { mainText } = suggestion | ||
const { offset, size } = suggestion.mainTextMatchInterval | ||
return ( | ||
<div className="truncate c-muted-2"> |
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.
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:
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 think it's fine, Wesley, thanks for the concern. Appreciate the level of care 😉
react/components/Combobox.css
Outdated
.option:active { | ||
background-color: #d2defc | ||
} |
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.
@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?
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.
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
)
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.
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 😉
@davicosta99
This task/PR only addresses the
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? |
react/LocationSearch.tsx
Outdated
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> | ||
) | ||
} |
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.
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 itmainText
: probably the street name (along with the number, maybe?)secondaryText
: larger administrative regions like city, state and countrymainTextMatchInterval
: used to highlight the part of themainText
that matched the user input. This can be improved to hold multiple matches and/or include thesecondaryText
, 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?
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.
Seems enough for me as well. I also don't believe we should include the secondaryText
in the mainTextMatchInterval
or multiple matches.
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.
react/LocationSearch.tsx
Outdated
<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> |
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.
can we opt in to a simpler markup? like the following
<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> |
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 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
.
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.
yep, it's an inline element inside another inline element, so I think we should be fine
@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. |
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.
LGTM, left a nitpick
react/LocationSearch.tsx
Outdated
<span className="b">{mainText.substr(offset, size)}</span> | ||
{mainText.substr(size + offset)} | ||
</span> | ||
<span>{` ${suggestion.secondaryText}`}</span> |
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.
sorry I missed this in the last review, but it's just a nitpick
<span>{` ${suggestion.secondaryText}`}</span> | |
{' '}<span>{suggestion.secondaryText}</span> |
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.
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' |
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.
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.
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.
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.
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.
LGTM
What problem is this solving?
Continuation of #17 and #20, implements the styling part of the following component.
How should this be manually tested?
Usage example