Repository navigation
Make RawAutoComplete only update the text value if onSelected is null #123377
Description
Use case
Right now, RawAutoComplete will update the text value when the user selects an option. The developer can control what value is set using displayStringForOption.
This system is very convoluted if you want to do something like trigger an action on selection and then clear the text field. Or if you're implementing a Twitter style @<user_name> feature where only a part of the textfield needs to be overwritten. The latter is especially messy with the current API.
Proposal
- If
onSelectedis null, no difference in behavior - If
onSelectedis non-null,RawAutoCompletewill not update the text value. The developer is expected to do so themself in the body ofonSelected - Remove
displayStringForOption. Given the above behavior, it would be redundant.
It'd be a bit sloppier, but instead of introducing a subtle breaking change by modifying onSelected we could instead introduce another attribute with the above functionality called handleSelection or similar.
CC @justinmc as this is an extension of our Twitter conversation here: https://twitter.com/justinjmcc/status/1639116016591720450
Activity
caseycrogers commentedon Mar 24, 2023
I found another use case that complicates things. I now think a more significant overhaul is justified here:
I'd like to pick the currently-scrolled-to option when the user submits the text field (ie presses enter/taps the check button). As far as I can tell, this is very complicated with the current API:
The
onFieldSubmittedcallback needs to know the state ofoptionsViewBuilderto know which option is currently hovered.So, my new proposal (on top of the new behavior suggested previously) is that all the non-widget tree dependent callbacks be moved into a
RawAutoCompleteControllerandRawAutoCompletebe given acontrollerargument.The
RawAutoCompleteControlleris a change notifier that notifies on:Iterable<T> options,T hoveredOptionorT selectedOptionchanging.RawAutoCompleteControllercould either extendTextEditingControlleror contain aTextEditingController(composition feels more appropriate here, but is a little verbose for a developer who just wants to pass in aTextEditingController). This wayRawAutoComplete.textEditingControllercould be removed to avoid redundancy.hoveredOptionis set by the developer from withinoptionsViewBuilder.While we're at it, maybe make options a generic? This makes it much easier to write an options builder that relies on extra state. See the following example:
The count is the total server count, NOT the locally fetched count so I have to pass in a class that implements
Iterable<T>and then cast it back to my subclass inoptionsViewBuilder.This allows the user to depend on the options state from outside of the
RawAutoCompletecallbacks.Note: I understand that this is a very large ask. I'm perfectly happy to write up an API proposal doc and write the PRs myself. But before I put in a lot of personal work I just want to know that my proposals have a decent chance of making it into
flutter/flutterso that I don't waste my time.I did a very similar
controllermigration already forDraggableScrollableSheetthat is now in production.wip RawAutocomplete: Let caller control options directly