-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Description
The Autocomplete and RawAutocomplete widgets are currently hard-coded to always show the options below the input field.
This works great for many use cases. But in some use cases, the options should always appear above the field, and never below.
For example in a messaging application, the input field for composing a message is typically pinned to the bottom of the view, just above the keyboard. There's then no room for autocomplete options below that field, and it should instead go above.
There've been a few previous requests in the tracker for this feature:
- With the use case of a field in a bottom sheet (so again the options should always go above, never below): Flutter AutoComplete in bottomSheet should show in upside on textfield #117836
- With the use case of another UI with the field at the bottom (a comment on an issue asking for the related dynamic version mentioned below): Autocomplete should automatically place options above or below based on where fits #101620 (comment)
- and in a downstream project's tracker: Is there a way to influence which direction (up/down) the dropdown appears? zsoerenm/chips_input#19
There've also been a couple of requests for a related feature — to have the options dynamically appear either above or below, depending on where there's room:
- Autocomplete options customizability #74509 (comment)
- Autocomplete should automatically place options above or below based on where fits #101620
The dynamic version would also be great, but seems more complicated. So I'd like to leave that as a future issue, and just design the API in a way that leaves the door open to cleanly supporting that feature later.
Specifically, I propose adding to RawAutocomplete and Autocomplete a field
with a name like alignment whose type is an enum like
enum AutocompleteAlignment { above, below }and that defaults to AutocompleteAlignment.below. Then in the future the dynamic version can be a third value for the enum.
Related issues:
-
Proposal for a more general form of customization that would subsume this: Autocomplete options customizability #74509
I think even in a future where we implement that more general feature, an
alignmentfield (or analignmentparameter on the constructors, anyway) would still be useful to provide a simple way to make a common choice. -
A request to decompose Autocomplete more generally: Decomposing DropdownButton and Autocomplete #99619
-
Controlling width, rather than vertical position: Autocomplete widget goes out of screen from right side #78746