Go, No Go For Launch

Behind the scenes this week I have been extremely busy with the new site launch.

All being well, I anticipate sending out the first batch of emails today. If you’re an active site subscriber, please keep an eye on your inbox.

I still have a bunch of outstanding tasks before then, so I’m going to keep today’s update short and sweet.

Whilst I have your attention would you mind hitting reply and letting me know:

If you could see a video / course on the site that would help you right now, what would it be about?

Thanks!

This week saw three new videos added to the site:

#1 – Dependency Injection and Symfony Services (Updated for 3.3)

First up we are covering the recent changes to Symfony’s approach to Dependency Injection.

One of the recurring issues I see with many developers who are new to Symfony is in understanding how to access Services from other Services.

See, it’s fairly obvious in a Controller. There are a lot of examples about, and particularly in the docs this use case is covered a lot.

However, after a short length of time in using Symfony you will inevitably migrate from everything in your controller, to controllers making use of services.

This means creating your own services.

And these services need access to other services – whether they are services provided by the Symfony framework, or ones of your own / your team’s creation.

I often see the same mistakes being made here, so wanted to cover this in a video I can refer developers to in the future.

#2 – An Introduction to Symfony Events

I make a heck of a lot of use of Symfony’s event dispatcher.

Typically these days I try to keep my controller actions as small as possible, and one way to do this is to dispatch events when things happen during a controller action.

This is better illustrated with some code, so here goes:

    public function postAction(
        Request $request,
        EntityManagerInterface $em,
        EventDispatcher $eventDispatcher,
        CourseFactory $courseFactory
    )
    {
        $form = $this->createForm(CourseType::class, $courseFactory->create(), [
            'csrf_protection' => false,
        ]);

        $form->submit($request->request->all());

        if (!$form->isValid()) {
            return $form;
        }

        $course = $form->getData();

        $em->persist($course);
        $em->flush();

        $eventDispatcher->dispatch(
            Events::COURSE_CREATED,
            new CourseCreatedEvent($course)
        );

        $routeOptions = [
            'slug'    => $course->getSlug(),
            '_format' => $request->get('_format'),
        ];

        return $this->routeRedirectView('get_course', $routeOptions, Response::HTTP_CREATED);
    }

This is an example of a controller action from the new version of CodeReviewVideos.

This controller action allows me to create new courses, and do the majority of the common stuff inside the controller action.

I use a form to ensure the data being submitted is valid according to my business rules.

I create the course with a factory, because I no longer use Doctrine’s lifecycle events for created at / updated at.

I still save / persist the new course in the controller action. More on this in a sec.

I then dispatch an event to say, hey, a new course has been created.

At this point other interested parties (registered listeners / subscribers) can ‘hear about’ this event, and take some appropriate action.

Examples of this are writing some data to the log. Or in this case specifically, indexing the new course within Elasticsearch.

The good news is the controller action needn’t be concerned with any of that stuff. It just ensures an action is dispatched, and my concerns are nicely decoupled.

Back to why I persist in the controller still, though.

I did try moving this logic to a separate subscriber, and it did work. But I didn’t like it. It didn’t feel right, for me. Your opinion may vary, of course, and that’s cool too.

#3 – Keep Constant, and Dispatch Events from Services

There’s two parts to this video.

First, rather than rely on strings for our event names, it’s better – in my experience – to use a Constant instead.

To begin with we cover one approach to doing this. It may seem trivial, but on larger projects your sanity will be thankful 🙂

Secondly, and tying in with the video #1 above, we look at how we can dispatch events from our own Symfony services.

This second part is almost a recap of video #1, albeit a little faster, and more specific to dispatching events. The reason I cover this topic twice is because the original email I received regarding events mentioned this particular problem, which led to me creating this new short series on Symfony events in the first place.

That’s all from me for this week. Until next week, have a great weekend, and happy coding.

Chris