Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Form][DX] Add choice_filter option to ChoiceType#28607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ro0NL left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
very nice 👌
| privatefunctioncreateChoiceList(array$options) | ||
| { | ||
| if (null !==$options['choice_loader']) { | ||
| if (null !==$options['choice_filter'] &&$options['choice_loader']instanceof ChoiceFilterInterface) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
i think something should happen when the choice loader does not supportChoiceFilterInterface. E.g. wrap it in a decorating / callback loader, or throw.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
yeah, I think throwing an exception is a good DX 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Decorating is not an option, because we lose the filtered list or the custom logic insideloadValuesForChoices andloadChoicesForValues in the decorated loader.
| // Harden against NULL values (like in EntityType and ModelType) | ||
| $choices =null !==$options['choices'] ?$options['choices'] :array(); | ||
| if (null !==$options['choice_filter']) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
&& $choices? Not sure it matters much... =/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
sure, should save some useless function calls 👍
| /** | ||
| * {@inheritdoc} | ||
| */ | ||
| publicfunctionsetChoiceFilter(callable$choiceFilter) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Wild thoughts, as I don't know all the implications right now: I don't know if a new interface with a setter is a good idea. Shouldn't we simply inject in the loaders' constructors thecallable $choiceFilter instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
👍 makes sense, to keep compatibility with any choice_loader we could still decorate it if the choice filter wasnt injected initially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I expected this question :) My goal is enable this feature for all (more and more used)CallbackChoiceLoader in current projects, automatically.
Otherwise, the feature will be enabled only for core types (e.g. Intl form types,EntityType) and will require more code and then more maintenance (injecting the$options['choice_filter'] everywhere).
This was the simplest solution I found to achieve a better DX, so callback loaders don't need to do something to enable this option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Also, this would allow for custom choice loader to enable this feature without care about injecting$options['choice_filter'] everywhere the loader is used. We only care about the implementation as a plug-and-play interface.
Btw, there are many examples of interface with a setter into the core, I'm not sure it's a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
see#28624 for a different approach
543962b tofa0a5e3Comparexabbuh commentedOct 1, 2018
yceruto commentedOct 1, 2018
Sure :) I need some time to review#28624 deeply, but it looks good to me. |
Alternative of#18334 and#28542.
This is what we can do with this new option, before#28542 (comment), after#28542 (comment):
In addition, we can use it with
EntityType, to filter choices thanks to dynamic properties or methods that could not be used with a custom query builder.This approach would filter the choices data just after loaded. This way, even filtered choice lists would be properly cached.