-
Notifications
You must be signed in to change notification settings - Fork 223
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
autocomplete: Options list can persistently lag behind query #226
Comments
This isn't nearly ready for merge; it's just to demonstrate a direction that might be helpful for zulip/zulip-flutte#226, and perhaps also for: flutter#123377 (comment) The idea (for zulip/zulip-flutte#226) is to move to a new class RawAutocompleteController the state value for the current list of autocomplete options. Then, to let RawAutocomplete's caller pass an instance of that class, giving the caller control over when that state gets updated. For us, that's better than accepting RawAutocomplete's old behavior, where a change in the TextEditingController was the only trigger for an update. (We want to trigger updates when our MentionAutocompleteView changes.) Ideally, we could add this capability to RawAutocomplete without removing any of its current API: maybe we could make the `controller` param optional, and I guess add asserts to try to prevent buggy mixtures of the old and this new opt-in behavior. Anyway, that that was way too tricky for this demo, so here I've just ripped out all the parts where RawAutocomplete did anything with the TextEditingController. I think our zulip/zulip-flutter#226 doesn't create a need to control the "selection" state, but that state is also moved to the RawAutocompleteController class anyway. Why? - Well, with RawAutocomplete being unaware of the text-input value, as mentioned in the previous paragraph, it can't listen for changes in that value, which it was doing before, to null out the selection state when the text changed. So, now we do that. - Also, I think there's a proposal for class like this RawAutocompleteController to contain the selection state: flutter#123377 (comment) That comment would also have it include the highlighted state, I think (which the auther calls the "hovered" state). Since those are closely related to the options-list state, might as well put them there along with it. For this demo, I hacked down the Material `Autocomplete` widget so that zulip-flutter would build, and I haven't touched any of the Flutter framework tests.
…dates This depends on my `wip-raw-autocomplete-options-demo` branch in my Flutter fork: flutter/flutter@master...chrisbobbe:flutter:wip-raw-autocomplete-options-demo Related: zulip#226
For a brain-dump of one possible approach, where we have |
A user reported this symptom in beta feedback:
(They saw it with topic autocomplete, not @-mention autocomplete, but we use some of the same code for both and that code is where the bug is.) |
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Co-authored-by: Zixuan James Li zixuan@zulip.com Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Co-authored-by: Zixuan James Li <zixuan@zulip.com> Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Co-authored-by: Zixuan Li <zixuan@zulip.com> Fixes zulip#1121.
This commit reverses the list that was originally presented to the user while showing the typeahead menu. This makes sense since on mobile its easier to click on options closer to the input box, i.e. where your fingers are currently present, instead of pressing arrow keys on a keyboard which is true on a desktop setup. Hence we place the best matching options not at the top of the typeahead menu, but instead put them at the bottom for better reachability and convenience of the user. Tests have been added to verify the emoji and mention render behavior. Also mentions dependencies on zulip#226 where required. Co-authored-by: Zixuan James Li <zixuan@zulip.com> Fixes zulip#1121.
It's normal for the options list to lag behind the query by some small amount, perhaps several milliseconds, because we do expensive filtering computations asynchronously.
The symptom here is different: for example, you type "@", and after waiting even multiple seconds, the list of @-mention autocomplete options doesn't come up. That's because RawAutocomplete updates the list with a listener on the
TextEditingValue
, not on theMentionAutocompleteView
.To recognize a change from one result set to another, we should have the UI listen and respond to
MentionAutocompleteView
, notTextEditingValue
.The text was updated successfully, but these errors were encountered: