The asset() Function & assets.context

Hey YinYang,

And that's OK, right? What do you think it should return? See the explanation below:

> If our app lives at the root of the domain - like it does right now - this will just return and empty string. But if it lives at a subdirectory like thespacebar, it'll return /thespacebar.

So, if your project is not in a subdirectory - that's OK :)

Cheers!

Yo Renaud G.!

Really interesting question :). In practice, both are probably fine. I used RequestStackContext because technically that's what the Twig asset() function uses internally. And so, we're exactly matching its behavior.

Here's what happens behind the scenes - it should help clarify a bit:
1) Symfony boots up and creates a Request object with all the data inside
2) When Symfony's router executes, it uses the data from the Request to set the data on the RequestContext - https://github.com/symfony/symfony/blob/e60a876201b5b306d0c81a24d9a3db997192079c/src/Symfony/Component/HttpKernel/EventListener/RouterListener.php#L77-L86 - that means that (in practice) the data in Request and RequestStack are identical.

That's why... probably both will work fine. However, there is at least one edge case: running code inside a custom console command. If you run code inside a custom console command and need to generate absolute URLs, because there is no request, generating absolute URLs doesn't work (the domain "localhost" will be used). To work around this, you need to set two parameters - we show that here: https://symfonycasts.com/screencast/mailer/route-context#codeblock-414154c720

The point is, when you do that, that data is set on the request context not the request. In other words, if you correctly added these parameters so that your custom console command behaves correctly but then rely on the Request inside of the code in this video (instead of the RequestContext) it would not work.

The tl;dr is: we use request context because that's what asset() uses internally... and it guarantees our code behaves exactly like it :).

Cheers!

Thanks Ryan! I'm still having a hard time wrapping my head around how you went from asset to RequestStackContext. Asset pointed me to Packages that pointed me to Package that has a ContextInterface that is apparently instantiated at runtime with a RequestStackContext but oh boy how should I have known that?
Some concepts are still a bit opaque to me and make me wonder what else I might be doing wrong unknowingly.

Hey Renaud G.!

I'm still having a hard time wrapping my head around how you went from asset to RequestStackContext

This is a particularly tricky/deep one to figure out.

Asset pointed me to Packages that pointed me to Package that has a ContextInterface that is apparently instantiated at runtime with a RequestStackContext but oh boy how should I have known that?

Well done following the trail! I'm impressed! Once I aw that some Package object/service had a ContextInterface argument, I would be wondering: "I wonder what service that "ContextInterface" argument truly is"? I personally then dig into core XML files in Symfony to find the service definition (you can also grep symfony/vendor for this interface to help find those), but you can usually also get help from bin/console debug:container. Something like this series of commands:

./bin/console debug:container | grep Package
./bin/console debug:container assets.packages --show-arguments
./bin/console debug:container assets._default_package --show-arguments
./bin/console debug:container assets.context --show-arguments

Try those commands and see if you can follow how I'm jumping from level to level. The last command ultimately tells me that the ContextInterface argument is really the service id assets.context, which is an instance of Symfony\Component\Asset\Context\RequestStackContext. THAT is how I dig up what low-level service does this work. It's one of the most difficult examples of "trying to figure out what Symfony is really doing behind the scenes". So honestly, I think you're doing really well :).

Cheers!