-
Notifications
You must be signed in to change notification settings - Fork 35
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
Fix autocomplete not having filter blank after selecting an item, and fix #540
Conversation
} | ||
}, | ||
|
||
// == Observers ==================================================== | ||
|
||
observeSelectedItemLavelChange: observer('value', 'options.[]', '_isTyping', 'filter', function () { |
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.
Lavel?
const selectedItem = this._findSelectedItemGivenValue(value, options) | ||
if (!isEmpty(selectedItem)) { | ||
const label = get(selectedItem, 'label') | ||
if (!isEmpty(label) && isEmpty(filter) && !isTyping) this.set('filter', label) |
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.
So I'm having a tough time understanding what the fix is. Do you mind posting screenshots/vids of the before and after. From what I can understand from these changes, it looks like the filter
was empty previously and you're setting it the the selected item label when user is not typing? Is that correct?
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.
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.
Interesting. Originally I was thinking that if a user started typing, it meant user intention was to set the value (even with backspace to clear) so it shouldn't need to set the filter back to the original. But autocomplete
isn't like Google's auto suggest. A value is only made with a selection and filtering the list shouldn't clear the value.
This was easier to handle in select
because there was clear separation between the filtering input and the value's input element. In select
typing anything would update the filter to whatever the user typed, regardless if it was empty. If the user didn't like the choices, he could close the dropdown and get back his original value.
Would it be better to keep track of the dropdown states instead of the typing? If the dropdown is open, don't override the filter ever; just keep it at whatever the user typed. Hmm. that would mean you'd also have to fix the automatic closing of the dropdown when they backspace to clear. Man, this component is getting really complex.
Up to you I guess. If I had a hard time understanding this scenario, others will and it'll be hard to maintain. Perhaps throw in some comments explaining this.
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.
The problem, in this case, is I don't have knowledge on whether drop-down is open or not. That's in frost-autocomplete
, and since we need to use onInput
for querying/etc we can't really have frost-autocomplete
control filter for us (because frost-autocomplete
assumes if you use onInput
you will control the filter
, and shouldn't set it.
I think I made it much more readable now by removing the observer logic, I'll add some comments on _isTyping
to make it easier to read
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.
Looks like drop-down state is also closed when you have an empty filter. So I'd run into the same issue
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.
Thanks, removing the observer business definitely makes this more readable.
|
||
this.setProperties({ | ||
filter: filterValue, | ||
_isTyping: 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.
Interested to know why it's necessary to keep typing state. Is there no alternative?
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 probably just need to get a better understanding of the bug you're fixing.
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.
Ya I'll add some screenshots/gifs tomorrow to better explain the problem
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.
Overview
Does this PR close an existing issue?
No PR should be opened without opening an issue first. Any change needs to be discussed before proceeding.
Summary
Provide a general summary of the issue addressed in the title above
Issue Number(s)
Which issue(s) does this PR address?
Put
Closes #XXXX
below to auto-close the issue that this PR addresses:Screenshots or recordings
Please provide screenshots or recordings if this PR is modifying the visual UI or UX.
Checklist
Semver
This project uses semver, please check the scope of this PR:
Examples:
ember-hook
selectorsember-hook
selectorsCHANGELOG