Active
Project:
Drupal core
Version:
main
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
19 Jul 2023 at 07:36 UTC
Updated:
19 Jul 2023 at 08:25 UTC
Jump to comment: Most recent
Problem/Motivation
From Drupal 10, we use Symfony 6
Symfony 6 deprecated using random strings for dispatching events.
Before $dispatcher->dispatch($event_class, $event_string_identifier)
After $dispatcher->dispatch($event_class)
In the second approach, the identifier defaults to get_class($event_class)
Event subscribers can then use SomeEventClass::class for the keys to \Symfony\Component\EventDispatcher\EventSubscriberInterface::getSubscribedEvents
However both approaches are still supported.
We should decide which one we will accept for new code.
Proposed resolution
Decide if we want all new code to just use EventClass::class or if we want to continue with a stand-alone MyModuleEvents class with string constants for the event names.
Examples showing both approaches
#2986669: Split ImageStyle into the config entity and a separate event-based image processing service
https://git.drupalcode.org/project/drupal/-/merge_requests/2691
#3100732: Allow specifying metadata on JSON:API objects
https://git.drupalcode.org/project/drupal/-/merge_requests/2794
One advantage of the old approach (Event class with constants) is there is somewhere for documentation all the events from a particular module/subsystem
One advantage of the new approach is you can add a subscriber based on the event rather than needing to look up a constant in a separate file.
Comments
Comment #2
mondrake+1 from me on
.
This is also consistent with other features in Symfony that tend to reduce boilerplate like e.g. autowiring where with latest practice you now define services with the class or the interface FQCN vs a string.
Comment #3
bbralaThe fact the old approach is deprecated makes me think using event classes is the way to go. The documentation argument might be True for core itself, if we choose to aggregaten events in an event namesoace, but for core modules they still live in the subsystem.
Also. Less files, code and developer rabbitholes to dive into finding stuff. Even though these rabbitholes are pretty shallow.
Perhaps for core events a naming scheme could help.
Anyways my vote would be for using the non deprecated method, :class.
Comment #4
mondrakeBTW - the events recently added to the Database API https://git.drupalcode.org/project/drupal/-/tree/11.x/core/lib/Drupal/Co... are an implementation of the second approach, already in core.