[DoctrineBridge][Form] Introducing new LazyChoiceLoader class and choice_lazy option for ChoiceType

[yceruto]

Q	A
Branch?	7.2
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	#57724
License	MIT

It's quite usual to work with forms that process large datasets. In Symfony Form + Doctrine ORM, if you define an EntityType, it typically loads all choices/entities fully into memory, and this can lead to serious performance problems if your entity table contain several hundred or thousands of records.

The new LazyChoiceLoader class addresses this performance issue by implementing an on-demand choice loading strategy. This class is integrated with any ChoiceType subtype by using a new boolean option named choice_lazy, which activates the feature.

Basic usage in a Symfony form looks like this:

$formBuilder->add('user', EntityType::class, [
    'class' => User::class, // a ton of users...
    'choice_lazy' => true,
]);

How does it work?

The loader operates by keeping the choice list empty until values are needed (avoiding unnecessary database queries). When form values are provided or submitted, it retrieves and caches only the necessary choices.

As you can see in the code, all this happens behind the LazyChoiceLoader class, which delegates the loading of choices to a wrapped ChoiceLoaderInterface adapter (in this case, the DoctrineChoiceLoader).

Frontend Considerations

Certainly, you may need a JavaScript component for dynamically loading <select> options, aka autocomplete plugins. You'll need to develop the endpoint/controller to fetch this data on your own, ensuring it corresponds to the form field data source. This aspect is not included in this project.

As a point of reference, the Autocomplete UX Component now uses this choice loading strategy, simplifying its autocomplete form type to a single field:

A Handy Use Case without Javascript?

The disabled option renders an EntityType form field read-only, and when combined with the choice_lazy option, it prevents the loading of unnecessary entities in your choice list (only the pre-selected entities will be loaded), thereby enhancing performance.

---

Hope this helps to create simpler autocomplete components for Symfony forms.

Cheers!

[yceruto]

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 special EntityToIdDataTransformer. Now they can use the EntityType directly with the choice_lazy option activated.

[Seb33300]

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 special EntityToIdDataTransformer. Now they can use the EntityType directly with the extra_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.

[Pixelshaped]

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.

[stof]

I'm not sure this extra_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).

[yceruto]

@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. The choice_lazy option facilitates this for DoctrineType although its use is not restricted to that purpose alone.

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

[yceruto]

Thanks @xabbuh for your review! I also added two test cases more about multiple option combined with choice_lazy.

[yceruto]

Just rebased to fix conflicts.

[nicolas-grekas]

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

[stof]

@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).

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

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

[yceruto]

@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 using block_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 🙏

[yceruto]

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 a choice_loader even without lazy loading.

[yceruto]

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

[nicolas-grekas]

Thank you @yceruto.