Good idea, please add tests. 🙂

That would be awesome !

I'm 👎 as we can now easily inject services in controller methods. The code is more explicit and as short (and there is then no need to extend the AbstractController class):

namespace App\Controller;

use Symfony\Component\Notifier\Notification\Notification;
use Symfony\Component\Notifier\NotifierInterface;

class SandboxController
{
    /**
     * @Route("/onboarding", name="onboarding")
     */
     public function __invoke(NotifierInterface $notifier): Response
     {
       $notification = new Notification('Welcome Sma <3', ['chat/slack']);
       $notifier->notify($notification);
       // stuff
     }
}

I agree with Fabien here, personally I tend to not use AbstractController anymore, as it makes clear the real dependencies of the class/controller.

The goal of AbstractController is to avoid boilerplate code for common dependencies and tasks, which is what this does.
Even though I don't use it much myself, I think it makes sense as an alternative. Plus, it gives an overview of controllers capabilities which is nice for discovery.
I'm 👍 here, in case we can reconsider.

No hard opinion on this 👍🏻

Thank you for your feedback.

I'm 👎 as we can now easily inject services in controller methods

Many helpers in the Abstract can be injected as well but are stil available via shortcut (Twig, Messenger...) or can be use without the Abstract (throw a notfound or deny access...)

Even I personally don't extends the AbstractController many developers and newcomers does. Some of them are not comfortable with dependency injection via Interface.
Having this helper let them kick in Symfony without struggle with these concepts

The cons arguments are relevant but I think this feature is a nice to have and doesn't have bad impact

Hi! I'm also leaning towards 👎 here.

I think the controller helper methods function to reduce boilerplate of things commonly done inside controllers. With the exception of dispatchMessage() (which I honestly didn't know existed, I'm not a huge fan of it either), all methods relate to HTTP world things: building responses, retrieving request info, forms and getting the authenticated user. I don't want to advocate using non-http world things in a controller, as that will encourage building big controllers. For instance, there are also no dispatchEvent() or sendMail() methods.

personally I tend to not use AbstractController anymore, as it makes clear the real dependencies of the class/controller.

Same. I have stopped using that class years ago and when I give trainings, I usually recommend not to use it. But I acknowledge that it is convenient, especially for new users, to use AbstractController because it makes framework features discoverable.

If developers should avoid using AbstractController, why do we still have that class anyway?

We have it as starting point and the most common use cases and we should keep it. The question is, is notifier a common/basic use case? For me not, but I am ok to add this.

WDYT @fabpot ?

Thanks for the discussion. I'm now definitely against merging this PR:

• AbstractController should indeed only be about HTTP related features (everything else should be done in other classes)
• I don't buy the difficult concept here, we are talking about type-hinting an argument in a method. I don't even think it makes things more or less discoverable as people using the notifier are probably reading some docs before using it.

I've submitted #42422 to take into account our discussion.

Thanks for the discussion, now the role of the AbstractController is clear for all of us. 👍🏽
I'll close the PR 👌