-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Display custom options view while options iterable waits to be resolved or is empty #147900
base: master
Are you sure you want to change the base?
Conversation
…th-empty-iterable
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.
We need make a final decision on if this 2-boolean approach is the best way to go. It looks pretty good in this PR. Maybe the error case that I mentioned in the comments is something we should make sure that it can do. Is there anything else that this 2-boolean approach would not cover? How about that issue that I tagged you in earlier?
/// | ||
/// This means that the original function will be called only after no calls | ||
/// have been made for the given Duration. | ||
_Debounceable<S, T> _debounce<S, T>(_Debounceable<S?, T> 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.
If you totally removed the debouncing from this example, would it be easier to understand the new stuff, or would it be too unrealistic?
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.
Yes, but it might also make it difficult to understand why _isLoading
should be set to false only when the current text is equal to the last text searched with (_lastValue
). So, if someone were to dup the example, remove the (seemingly) extra variables _lastOptions
and _lastValue
and later add debouncing, they would probably run into errors and get confused.
@@ -353,6 +366,9 @@ class _RawAutocompleteState<T extends Object> extends State<RawAutocomplete<T>> | |||
// Called when _textEditingController changes. | |||
Future<void> _onChangedField() async { | |||
final TextEditingValue value = _textEditingController.value; | |||
if (widget.showOptionsViewOnUncompletedOptions){ | |||
_updateOptionsViewVisibility(); |
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.
How does this affect synchronous values of optionsBuilder? optionsViewBuilder could be called twice back-to-back. Is that something we should avoid or it shouldn't matter?
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.
If optionsBuilder
is synchronous, and showOptionsViewOnPendingOptions
is set to true, then the options view will just be rebuilt to display its current contents.
I've added a note for users to ignore showOptionsViewOnPendingOptions
if their optionsBuilder
is synchronous.
Bug report on the example: Screencast.from.2024-05-20.12-02-59.webmUsing the same steps, one time I also saw the "Loading" disappear and a few seconds later the correct results appeared. Couldn't capture that in the recording though. It probably has to do with subtle timing. |
Fixing this bug required me to revert the change which terminates I was also running into another bug where if there was a selection and the app window goes into the background, when the text field is refocused, the loading message displays infinitely. To fix that, I use |
@@ -157,6 +157,8 @@ class RawAutocomplete<T extends Object> extends StatefulWidget { | |||
this.onSelected, | |||
this.textEditingController, | |||
this.initialValue, | |||
this.showOptionsViewOnEmptyOptions = false, | |||
this.showOptionsViewOnPendingOptions = false, |
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.
It seems to me that these two flags have a lot in common: they both want to show the options view. I think that's a sign that the API could be more generic / flexible. Can we let the user specify what the logic in _canShowOptionsView
should look like, and have the current behavior as the default?
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 thought the same thing. I'd like to see what that would look like.
bool get _canShowOptionsView => _focusNode.hasFocus && _selection == null && _options.isNotEmpty; | ||
bool get _canShowOptionsView => _focusNode.hasFocus && _selection == null && | ||
(_options.isNotEmpty | ||
|| widget.showOptionsViewOnEmptyOptions |
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.
nit: { }
for multiline expressions per the style guide, instead of =>
.
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.
Also the logic doesn't seem correct? showOptionsViewOnEmptyOptions
and showOptionsViewOnPendingOptions
seem to have the same effect here, but they are different flags?
Currently in
Autocomplete
, there is no way to:Display a custom options view when the options returned from
optionsBuilder
is empty:Autocomplete widget calls optionsViewBuilder even when optionsBuilder return empty Iterable #108258
This is useful if one wants to display a custom message when the field is focused for the first time, or when no options were found.
Display a loading message while waiting for the
optionsBuilder
future to be resolved.This PR fixes these issues by introducing two boolean parameters to
Autocomplete
andRawAutocomplete
:showOptionsViewOnEmptyOptions
andshowOptionsViewOnPendingOptions
.When set to true,
showOptionsViewOnEmptyOptions
displays the options view even when the options returned fromoptionsBuilder
is empty.When set to true,
showOptionsViewOnPendingOptions
displays the options view just before awaiting theoptionsBuilder
future, allowing a custom loading view to be shown while waiting for theoptionsBuilder
future to be resolved.Fixes #108258 and #147377.
Before:
autocomplete_b4.mov
After:
Autocomplete.video.mov
Pre-launch Checklist
///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.