Problem/Motivation
Since #3108309: Support Yaml::PARSE_CUSTOM_TAGS in \Drupal\Component\Serialization\YamlSymfony::decode we support custom tags in \Drupal\Core\DependencyInjection\YamlFileLoader but do not have explicit support for the !service_closure custom tag.
We already support this in the container with the #[AutowireServiceClosure('foo')] attribute.
This issue adds support for the !service_closure custom tag in services.yml files.
https://symfony.com/doc/current/service_container/service_closures.html
This feature wraps the injected service into a closure allowing it to be lazily loaded when and if needed. This is useful if the service being injected is a bit heavy to instantiate or is used only in certain cases. The service is instantiated the first time the closure is called, while all subsequent calls return the same instance, unless the service is not shared:
Steps to reproduce
Proposed resolution
Add support for !service_closure custom tag in YamlFileLoader
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3450516
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
kim.pepperComment #4
smustgrave commentedChange seems simple enough
Test-only failure shows also has coverage.
Solution matches what's proposed so believe this is good.
Comment #5
kim.pepperUpdated IS with more background
Comment #6
alexpottWe should have a CR for this... something like #3436859: Services can now use tagged iterators in services.yml files
Comment #7
alexpottONce #6 is done we can set this back to rtbc.
Comment #8
kim.pepperAdded a change record.
Comment #10
alexpottCommitted 72397df and pushed to 11.x. Thanks!
Fixed coding standards to comply with Symfony's and the rest of the file... spaces and yoda ifs...
Going to discuss with release managers about which releases this belongs in.
Comment #12
alexpottDiscussed with @catch we agreed to put in 10.4.x - and possibly 10.3 and 11.0 - will discuss some more.
Comment #15
alexpottDiscussed with @longwave and we agreed to backport this to 10.3.x