Bonus! LoggerTrait & Setter Injection

Hey boykodev

> But why make a setter required, if you could just add it to the constructor and achieve the same result?

Yep, you're correct but it was done that way so you end up with a reusable trait for logging messages and for teaching purposes.

> Is there a way to only inject dependancies that you actually used when calling service functions?

That's totally doable! it's called "Lazy Services", you can find more detailed info at the docs: https://symfony.com/doc/cur...

Cheers!

Hey mickaelandrieu!

Yea, this is the key thing that I don't like about setter injection too. When I use it, I still code defensively - i.e. I check that the property IS populated before using it. And so, I only use it for true optional dependencies. Honestly, the logger is one of the few :). You could totally create a system full of traits like this so that you could easily "fetch" them via setter injection... but even for me, I think that's not a great world :).

Any chance to see @required annotation accept somehow a condition using expression language or a fonction from the class itself?

Can you explain this a bit more? What kind of expressions would you use? The @required is really more of a flag to Symfony's container that says: "Hey! I actually want you to call this setter and autowire it". The annotation was invented so that the container wouldn't try to call & autowire EVERY method starting with "set" :)

Cheers!

Hello weaverryan!

I'm thinking about something like:

/**
* @required("kernel.debug == true") // need to think about what we could make available here...
*/
public function setLogger(LoggerInterface $logger = null) {}

Because the way I understand it, once you add the @required annotation the injection is not optional anymore!

So the only valid code (for me) would be:

/**
* @required()
*/
public function setLogger(LoggerInterface $logger) // will never be null in reality
{
// so no need to check for existence here!
}

Am I right, or there is some edge cases when - even with the @required annotation, the Logger could be null.?

Hey mickaël!

Sorry my slow reply on this - I got a little behind.

No, you’re totally right that once you have @required Symfony will call this 100% of the time. So, in practice, you don’t need to check for the existence of the property before you call a method on it.

It’s just that, from an object oriented standpoint, if you look st this class, nothing enforces that this settee was called. This could have practical implications in unit tests: if you forget to call setLogger, your code will fail. And actually, because the Logger really shouldn’t be needed to make the class work, you shouldn’t *need* to call setLogger(). So, by checking for existence, it just feels better from an OO perspective. And, I don’t need to unnecessarily call setLogger in a unit test.

Anyways, your idea about adding a little bit of logic in @required makes total sense! And that would totally be possible to implement. But, I don’t think it’s probably something that we need. Side note: if, for some reason, the Logger service were available in debug mode but not in prod mode, you could just make the argument optional (Logger $logger = null) as then it would not be set if the service didn’t exist (when the arg is required and the service doesn’t exist, you get an error).

Cheers!

Hey Guilherme,

Thank you for your feedback! Well, maybe someday you will *upgrade* your project to Symfony 6? :) We do have a few tutorials about upgrading major version of Symfony, you need to upgrade to the latest 4.4 in your case, then drop all the deprecations you have and upgrade to the 5.x, then repeat the same steps but with a different Symfony version. It's totally doable, but it might depend on the bundles you're using, and how big your project is, but it's doable ;) I'd recommend you to take a look at this course: https://symfonycasts.com/sc... - it might help you to make a decision.

Cheers!

Yeah that's my plan for the future, I don't get to take archithecture decisions yet but I'm certainly very much interested in the topic and with SymfonyCasts I can acquire the necessary baggage to start participating the discussions and cave my road. W'ell get there in time hehe (don't mind my English haha)

Hey Guilherme,

Good plan! ;) And good luck with your project, I hope someday you will upgrade it

Cheers!

Hey Robertas,

Thank you for this report! Unfortunately, it's difficult to spot the problem, could you point us, please? What exactly code is incorrect? DO you have a solution about how to fix it? I would be happy to fix the incorrect code for you :)

Cheers!

Sure, not so obvious, when the problem is not in the the code you don't have to change.

At line 37, there is old code:

public function show($slug, MarkdownHelper $markdownHelper, Client $slack)
{
if ($slug === 'khaaaaaan') {
$message = $slack->createMessage()
->from('Khan')
->withIcon(':ghost:')
->setText('Ah, Kirk, my old friend...');
$slack->sendMessage($message);
}

But it should be:

public function show($slug, MarkdownHelper $markdownHelper, SlackClient $slack)
{
if ($slug === 'khaaaaaan') {
$slack->sendMessage('Kahn', 'Ah, Kirk, my old friend...');
}

Just minor issue.

Hey Robertas,

Thanks for more details about it! Though I still can't find the code block on current page where we show that invalid code. I only see this one: https://symfonycasts.com/sc... . The code you mentioned is from SlackClient, i.e. we moved it from the controller to the service: https://symfonycasts.com/sc...

Or are you talking about a different chapter page? Could you link with me with the exact code block? You can click on filename in code block to generate a link to the code block.

Cheers!

Hey Raito,

Thank for mentioning this "Psr\Log\LoggerAwareTrait". Moreover, you can just use this trait instead of creating your own one ;)

Cheers!

Hey Bohan Y.!

Nice tip! You're on fire :)

Cheers!

Hey David P.!

Hmm. That is indeed strange - it should *not* work that way. Very simply, for each service (and both your console command AND service Y are services), the container looks to see if any of the public methods have the @required annotation above it. If it does, then it adds that as a "call" to the service. The *only* reason that it would not be doing this, is if service Y was not set to be autowired. But if you're using the default Symfony 4 config, all services that you register are autowired.

So, I'm at a loss, but I *am* interested: I just can't think of why it would *not* work. Would you mind posting some real (or at least realistic - you can change names) code? I might be able to spot the problem then :).

Cheers!

Oops. Failed to mention that the service, command, and trait are all part of a custom bundle (more about how I'm making that happen later).
I can post some code or turn this into a SO post. What would be best?
Thanks

Hey David!

Sorry for my slow reply! Ah, this help! The key thing is that the service needs to be autowired - the whole automatic setter injection thing happens thanks to autowiring. So, it makes me wonder if you might not be using autowiring in your custom bundle (actually, we usually don't use autowiring for shareable bundles, but if it's just your own code, it's totally fine). To find out, try running:

php bin/console debug:container id_of_your_service --show-private

This has an "Autowired" line to tell you if your service is autowired :).

Cheers!