A side note: if I knew how to get a list of options of that EntityType field's instance, we wouldn't need to list them manually. It would be enough to just take the current $options and remove any unsupported values from it before passing it on.

If there is a way to do that, please let me know, I'm happy to tweak things!

@janklan we should avoid words like "blacklist" and "whitelist", and prefer words that are more inclusive and convey real meanings.
Here are some good alternatives:

• deny list
• avoid list
• block list
• exclude list

@garak I think we don't need to get into politics of offensive language before this gets any real indication of whether or not it is even viable. Thanks for the feedback though.

@janklan it's not politics, it's just trying to be nice.
Symfony is making an effort for it, see for example https://symfony.com/doc/current/contributing/diversity/index.html

Anyway, even if you don't care about it and you want to consider it as "politics", I provided you with a very practical reason: the word "blacklist" simply doesn't convey the meaning you want unless you leverage a stereotype.

Using the word "blacklist" shouldn't be seen as "being not nice". The official definition in the Oxford Dictionary is: "a list of people or things that are regarded as unacceptable or untrustworthy and should be excluded or avoided.".

In the current context, it contains a list of options we wish to exclude from passing to the FormEntity, and as such, I think the name conveys the meaning perfectly reasonably well.

With that said, let's please go back to the technical aspects of this PR.

Thanks for your understanding
Just a final word to point out the false dichotomy of nice and not nice. The dictionary entry you mentioned is neutral.

@garak correct; neutral does not mean "not nice". I think neutral is great, especially in software. It's not a poem. It's code. It should be precise above all. autocomplete_excluded_options is more precise than autocomplete_blacklist, so that makes it better. Not the absence of the word blacklist.

Anyway, I have an opinion on these things that you would probably disagree with, and that's OK. Consider my opinion suppressed in favour of your opinion :)

The problem is that if you're neutral in an unbalanced situation, you're on the same side as the "not nice" ones.
And software is used by people, so it can't be neutral, not as long as you want to try to be nice.

Let's agree to disagree and let's get back to focusing on the subject of this PR. Thanks.

@janklan I like the idea behind this. It's not automatic, but it makes something work that doesn't currently work. If I'm understanding the use-case, it would be this:

A) I create an "entity autocomplete field" - like https://github.com/symfony/ux/blob/2.x/ux.symfony.com/src/Form/FoodAutocompleteField.php - but I add a custom option - e.g. hideJunkFood. Perhaps I use this to customize the query_builder option I'm using.

B) When using the field - like

->add('foods', FoodAutocompleteField::class, ['hideJunkFood' => true])

Am I thinking about this correctly? If so, then when the Ajax request is made to the autocomplete endpoint, won't we recreate the FoodCompleteField there but without this option? And so hideJunkFood would be true and we may return the wrong autocomplete options? If that is all true, then we should tackle the other half of this problem now: allowing some options (like hideJunkFood) to be passed as a query parameter on the autocomplete Ajax URL and passed back into the form type there.

Cheers!

I think this can be closed as there are no nested form type now, and you can provide everything same as with other form types

Yup & yay! Let us know if you have any issues with the new system