Sub Requests & Request Data

Hey @Houssem Zitoun!

Definitely! But the best examples are probably specific to your project. For example, suppose you frequently talk to an API to fetch data. You could set up a system where you can type-hint the object you need from the API in your controller and use an argument value resolver to actually make the API request and pass in that value.

Some projects might not have any use for custom argument value resolvers and that may be in part because the popular ones have already been implemented. For example, if you use Doctrine to fetch data, there’s no reason to implement an argument value resolver to automatically query for entity objects because that already exists.

Anyways, let me know if this helped :).

Cheers!

Hey @Rayan,

Yes ^^ !, if we had doctrine no reasons to implement a custom resolver, totally agree :)
Otherwise, I liked the use-case you gave me! Cool! (with your accent in the videos) so it reminds me of: assuming that to increase performance you need less code to run, is it better to consume the API "classically" or use a resolver ^ ^?

Cheers!

Hey Houssem!

> Cool! (with your accent in the videos) so it reminds me of

😂

> assuming that to increase performance you need less code to run, is it better to consume the API "classically" or use a resolver

The performance is identical, except for one important detail. Regardless of how you make the API call, you want to make sure that you *only* make the API call when you actually *need* that data.

So, for example: suppose you are have an argument value resolver that looks for a Product type-hint in an argument. If an argument has this type-thing, it makes an API call and passes this object to your controller.

If you had this situation, and had a "Product $product" argument on a controller... but then never actually *used* that argument, then you're unnecessarily making that API call. But... that's probably not very common: why would you have a "Product $product" argument to your controller if you didn't need it? Well, one legitimate case is if you have some if conditional...and you only need it under certain situations. That's probably not very common, but that would be an example where making the API call manually in your controller (only *exactly* if/when you need it) is better than the resolver.

But mostly, they're identical. If the current page will execute a controller that does NOT have a "Product $product" argument, then the resolver will do nothing and no API call will be made :).

However, to take this to the *next* crazy level of thinking: one thing you need to be aware of is that an argument resolver is instantiated on every request, even if it ultimately doesn't "resolve" any arguments. That's not really a big deal... unless the constructor of your resolver requires *other* objects.... and those require other objects... and suddenly you're instantiating 20 objects just so that your argument resolver can do nothing on 99% of the requests :). As similar thing happens with Twig extensions (which are always instantiated when you use Twig, even if you don't use any of the functions/filters provided by it), event subscribers and voters. This is an entirely different conversation, but since this is a "deep dive" course, I thought you might like to chat about it ;). Here's some more info about that: https://symfonycasts.com/sc...

Cheers!

OK! it's clear for me ^^!
Big thanks for fhe "deep dive course", I did not notice that it exist. I did instead this deep dive course :)
Last thing, but in other subject, I did 6 courses (6 certifacations) and I noticed that your did not talk about the sessions ^^, is there a reason?

Hey Houssem!

> and I noticed that your did not talk about the sessions ^^, is there a reason?

We get this question occasionally... and I really should cover it somewhere. The reason I don't talk about it much is that session are super easy. If you want to store something in the session, you can type-hint SessionInterface to get the service. Then it's a simple key-value store: use $session->set() to put something in and $session->get() to get it back out. All the session data is saved behind the scenes automatically. The only other complication is if you wanted/needed to change your session storage - e.g. to store in the database instead of on the filesystem. We don't have a video on that, but in part because the docs cover it pretty well - https://symfony.com/doc/cur...

But if you have any specific session questions, let me know :).

Cheers!

Hey hey hey @Rayan ^^!

We get this question occasionally... and I really should cover it somewhere.

Yes and please ^^.There are also a lot of simple concepts out there and you've covered it really well so that you have a lot of added value ^^, sometimes better than the documentation!

Cheers!