[Autocomplete] Fix bug of not using choice_value

[ytilotti]

Q	A
Bug fix?	yes
New feature?	no
Issues	n/a
License	MIT

The option choice_value (like EntityType) is not used in Autocomplete ux on AsEntityAutocompleteField class.

[yceruto]

It could be simpler for this autocompleter service if it built the form view (i.e., $view = $this->getForm()->createView()) and get the label and value already processed from $view->vars['choices'], so you wouldn't miss any native features that render those options.

[smnandre]

A particular reason for this change ?

[ytilotti]

To have only one use.

[smnandre]

I'm not sure this offers a better readability, but let's see what others think

[ytilotti]

I'm not sure this offers a better readability, but let's see what others think

Used in https://github.com/symfony/symfony/blob/7.1/src/Symfony/Component/Form/ChoiceList/Factory/CachingFactoryDecorator.php.
I have no personal opinion, whatever ;)

[smnandre]

The return type of the method is not compatible with all the new possibilities no ? Integers, floats, nulls, ...

[ytilotti]

Historically, there's already a "problem" when we see the return type of getIdentifierValues():

/**
     * Returns the identifier of this object as an array with field name as key.
     *
     * Has to return an empty array if no identifier isset.
     *
     * @return array<string, mixed>
     */
    public function getIdentifierValues(object $object);

But there is no problem because is always cast to string.

By default, PHP will coerce values of the wrong type into the expected scalar type declaration if possible. For example, a function that is given an int for a parameter that expects a string will get a variable of type string.

[weaverryan]

It could be simpler for this autocompleter service if it built the form view (i.e., $view = $this->getForm()->createView()) and get the label and value already processed from $view->vars['choices'], so you wouldn't miss any native features that render those options.

That's a really interesting idea. After all, our goal is to return the text and value that is rendered on the frontend. So creating the form view, then extracting from there makes a lot of sense. @ytilotti would you mind giving that a shot?

[ytilotti]

I don't see @yceruto's idea. Maybe he can suggest it?

[weaverryan]

Sorry for the delay @ytilotti - it's this idea: #1328 (comment)

So instead of getting the choice_value option from the form, then trying to handle the different types that it may be (which is, I admit, what I've done so far in other spots), what if we did something like this?

$view = $this->getForm()->createView();

return $view->vars['value'];

[kbond]

Thanks for your work here @ytilotti. This is now fixed via #1723.