Basic usage:

$builder->add('locales', LocaleType::class,array('choice_filter' =>function ($choice)use ($userLocales) {returnin_array($choice,$userLocales,true);    },));$builder->add('entities', EntityType::class,array('class' => \AppBundle\Entity\Issue::class,'choice_filter' =>function ($choice)use ($user) {return$user->canHandle($choice);    },));

Tests added.

This is a full BC implementation.

The only thing that should be noted in UPGRADE is that someone uses its ownChoiceListFactory should either implementFilteredChoiceListFactoryInterface or use theFilteringFactoryDecorator to use the newchoice_filter option, otherwise it will simply be ignored.

@stof any thought on this one regarding the previous (wrong) implementation ?

ping@webmozart :)

@HeahDude this will have to wait until 3.2. We are already in the 3.1 feature freeze, and there is still too much to evaluate about this feature to merge it now (we are not yet fully freezed as we allow us to include some PRs which are ready but not yet merged, but this feature cannot be considered as ready yet IMO).
So I will focus on the review of other PRs for now (the ones still considered for inclusion in 3.1) and come back at this feature later.

@stof I absolutely agree ;) Thank you for your feedback!

Status: Needs Work

@HeahDude : What about accepting an array in thechoice_filter option?

The following:

$builder->add('locales', LocaleType::class,array('choice_filter' =>$userLocales,));

will automatically generate the callable usingin_array.
It'll help when the type is configurable from a configuration file for instance (like in EasyAdminBundle).

will automatically generate the callable using in_array.

I like the idea, thanks! I'll try to implement it soon when revisiting this one.

@ogizanagi Just curious why not simply use thechoices option of theChoiceType in this case?

I expected this question 😅

This allows to blindly filter the available values, without caring of the implementation of the type. In a config file, you only want to use%locales% for instance (which only contains values).
Behind, the type has the responsibility to associate the proper labels for instance.

Using thechoices option of theChoiceType forces you to redefine everything.

I think you can already solve this case using a custom type:

class UserLocaleTypeextends AbstractType{publicfunctionconfigureOptions(OptionsResolver$resolver)    {$resolver            ->setRequired('display_locale')            ->setNormalizer('choice_label',function (Options$options) {$displayLocale =$options['display_locale'];returnfunction ($choice)use ($displayLocale) {return Intl::getLocaleBundle()->getLocaleName($choice,$displayLocale);                };            })        ;    }publicfunctiongetParent()    {return ChoiceType::class;    }}// Then you can do$builder->add('locales', UserLocaleType::class,array('choices' =>$userLocales,'display_locale' =>$userLocale,));

But I agree, the filter option definitely simplifies the implementation though :)

But regarding performances implementing a specific type like in my example may be better.

I agree. Such uses of thechoice_filter option will be reserved mainly for countries, locales, languages (...). I doubt it'll have a big impact on performances, but it has a very good one on DX.

Is this really something that will be commonly used? I mean if you need to filter your choices, why don't you just do that when specifying thechoices option then?

@xabbuh in case of inheritance there would be no need to define again thechoices and we could use the same cached choice list on which to apply the filter.

For theEntityType it would allow to filterchoices thanks to dynamic properties or method that could not be used with a custom query builder.

So to me this feature is the right answer to both needs.

@HeahDude Sounds reasonable to me. Do you think you can finish this one?

ping@HeahDude

@HeahDude Do you think you can work on finishing this PR or shall we close it?

Closing this PR as there is no more activity.@HeahDude Feel free to reopen whenever you have time to finish it. Thanks.

See alternative#28607