[Form] vague/incorrect information in article for dynamic form modification

[thedamnedrhino]

There is this paragraph inside the cookbook entry for dynamic form modification:

You might wonder, now that you have access to the User (through the token storage), why not just use it directly in buildForm and omit the event listener? This is because doing so in the buildForm method would result in the whole form type being modified and not just this one form instance. This may not usually be a problem, but technically a single form type could be used on a single request to create many forms or fields.

First of all adding a listener inside the buildForm method of a form type, will cause that listener to be added to all instances of that form type not just one instance.
Also, I think in that specific example adding the field directly in buildForm will result in the exact same Form. Because buildForm is called for every created form of that type separately, the only scenario in which these two approaches might produce different results, consists of the TokenStorage object changing it's state between buildForm is called on the FormType and setData is is called on the Form which is highly unlikely. If there is some other scenario that I'm missing, it should be clarified with an example.

[javiereguiluz]

Could any Form expert please verify if this is true? @yceruto @HeahDude @vudaltsov. Thank you!

[vudaltsov]

I agree with the author of this issue. More than that in the next section the user is "grabbed" outside the listener which does not correspond to the admonition.

[yceruto]

I also agree that the described example can be achieved without form events, even it would be best, but this topic is about form events, so we should find a valid example for How to dynamically Generate Forms Based on user Data.

In my opinion, the form listeners/subscribers make sense only if the underlying/submitted form data will be taken into account -> I suggest changing the example to something like this:

use App\Repository\UserRepository;

// ...

$builder->addEventListener(FormEvents::PRE_SET_DATA, function (FormEvent $event) use ($user) {
    if (null !== $event->getData()->getFriend()) {
        // this means that the message will be addressed to a fixed friend
        // so the friend field is not necessary in this form
        return;
    }

    $form = $event->getForm();

    $formOptions = array(
        'class' => User::class,
        'choice_label' => 'fullName',
        'query_builder' => function (UserRepository $userRepository) use ($user) {
            // call a method on your repository that returns the query builder
            // return $userRepository->createFriendsQueryBuilder($user);
        },
    );

    // create the field, this is similar the $builder->add()
    // field name, field type, field options
    $form->add('friend', EntityType::class, $formOptions);
});

// ...

It would justify the existence of the listener.

---

About the cited note, I also suggest moving it at the end of this example replacing the current note that seems unrelated to this topic.

[yceruto]

See #10061 for proposal.

[javiereguiluz]

Closing as fixed by #10061.