Add \Drupal::renderer() but document how and when it should be used

I was thinking of why we don't have this in \Drupal even though this is something that is (sadly) needed quite often.

Devil's advocate: Why is \Drupal::service('renderer') not acceptable?

Devil's advocate: Why is \Drupal::service('renderer') not acceptable?

Because this doesn't return the proper class/interface for allowing IDEs for proper auto completion.

IMO, this is more of a "helper/wrapper" method than anything so it links the class.

Consider the following:

/** @var \Drupal\Core\Render\RendererInterface $renderer */
$renderer = \Drupal::service('renderer');
$output = $renderer->render($build);

Opposed to just doing:

$output = \Drupal::renderer()->render($build);

This is more about DX IMO and reducing LOC and readability for when this actually is needed.

I just needed \Drupal::renderer()->addCacheableDependency($build, $foo); and this would have been handy for that. Unless there's another way to do that without the service, but couldn't see one.

Also, there are plenty of places where this can be useful, especially in themes btw, where we don't have the ability to simply inject the renderer, let alone the container. To just say "don't use it" isn't right.

Instead, it should be documented for it to only be used in places where there the render service hasn't been injected, not able to be injected nor has immediate access to the container.

So, setting back to CNW for documentation purposes.

$variables['renderer']

This would technically allow twig templates access to this as well. Considering that this is a class and not a string/render array, how would twig handle this if it's used. No, we already have the |render filter for twig. The variables array is meant for the consumption of things in twig templates, not to provide classes like this. I'd rather just have the helper method \Drupal::renderer for when it's needed in PHP.

Well, I was primarily thinking of preprocess functions.

I understand, but polluting the $variables array with a class like this is a no go. Variables are meant for consumption, not utilities. All themes can do is call \Drupal helper methods and I'm fine with that, do it all the time.

For every other usecase though, like in modules, you are doing something wrong, IMHO, when you use \Drupal itself.

Yes, I agree. However there are use cases in modules too: alter hooks (which is what @catch is referring to above).

That's why I set this back to CNW because there needs to be better documentation around "when" it's appropriate to use this.

I agree this would be a useful addition.

I also think it's potentially safer than not including it. By returning something type hinted, IDEs make it really obvious the renderer actually has a bunch of different methods, which I think encourages digging a bit deeper to understand the nuances between them and perhaps problems with rendering early in general.

Out of interest sake, I scanned a recent check-out of all D8 contrib projects and found that 'renderer' was the most frequently accessed service using the \Drupal::service method.

The top 5 were:

• 1006 renderer
• 706 config.factory
• 661 date.formatter
• 304 path.current
• 267 plugin.manager.filter

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.