Over there, there should be other special use cases, such as using API payloads against forms where the choice lists are not really necessary, so people work around with custom form types and specialEntityToIdDataTransformer. Now they can use theEntityType directly with thechoice_lazy option activated.

Over there, there should be other special use cases, such as using API payloads against forms where the choice lists are not really necessary, so people work around with custom form types and specialEntityToIdDataTransformer. Now they can use theEntityType directly with theextra_lazy option activated.

+1

I had a similar case few years ago with an API relying on a Symfony form with an EntityType loading thousands of choices.
I ended by adding the EntityType field to the form with an event on submit and filtering the SQL query to select only the items submitted by the user.

Thank you I was already using this code from UX Autocomplete and I think it's the right move to make it part of Doctrine Bridge as this is a very common use case, even if part of the solution is front end (one would still need to implement a route to get a paginated list of entities and pass it to Select2 or whatever solution you're using).

I had duplicated the ExtraLazyChoiceLoader in my project to not require UX Autocomplete (as I'm using Select2 already everywhere), and now I can use this and stay updated.

Nice job.

I'm not sure thisextra_lazy option in the existing type extending ChoiceType is the right option. Such autocomplete type requires a totally different rendering than a choice type (and this autocomplete rendering might make sense with data sources that are not from doctrine).

@stof certainly there's additional work required to create a fully-autocomplete type, which is not the goal of this PR btw. However, it does streamline implementations that previously needed custom/complex solutions. Thechoice_lazy option facilitates this forDoctrineType although its use is not restricted to that purpose alone.

I believe theLazyChoiceLoader is the main feature here. It's compatible with anyChoiceType and you can wrap any data source (Local Storage, External APIs, ...) allowing it to load those data efficiently by following this "on-demand" approach.

Thanks@xabbuh for your review! I also added two test cases more aboutmultiple option combined withchoice_lazy.

Just rebased to fix conflicts.

@nicolas-grekas this lazy mode assumes that you have a form rendering that does not need the list of available choices (and sonot rendering it as a<select> like the default rendering of a ChoiceType).

This is the reason why I suggested that it may fit better as aseparate form type instead (which would have a separate rendering).

Making all choice loaders wrapped in this LazyChoiceLoader in ChoiceType itself would break it.

@nicolas-grekas this lazy mode assumes that you have a form rendering that does not need the list of available choices (and so not rendering it as a<select> like the default rendering of a ChoiceType).

I can add that if there is data bound to that field (either default or submitted), it will render the choices as usual, rendering only the selected ones in this case.

This is the reason why I suggested that it may fit better as a separate form type instead (which would have a separate rendering).

I might be missing your point here. Still wondering how it could be different from the current one and why... you can currently have different renderings for the same form type usingblock_prefix option.

Making all choice loaders wrapped in this LazyChoiceLoader in ChoiceType itself would break it.

Sorry, I'm confused by this comment. Is it related to Nicolas' comment? Otherwise, could you please elaborate 🙏

Maybe stupid comment: can't we always behave lazily when choice_loader is set and get rid of the option altogether?

You might still want to use achoice_loader even without lazy loading.

This is ready on my side.@stof any blocker on your side?

Thank you@yceruto.