Contrib.social

[policy, no patch] Decide on policy regarding use of Events class with string constants for event names or class names instead

Open on Drupal.org →
Created on 19 July 2023, over 1 year ago

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

✨ Split ImageStyle into the config entity and a separate event-based image processing service Needs work
https://git.drupalcode.org/project/drupal/-/merge_requests/2691
✨ Allow specifying `meta` data on JSON:API objects Needs work
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.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component
Base  →

Last updated about 2 hours ago

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @larowlan
  • Comment over 1 year ago →
    🇮🇹Italy mondrake 🇮🇹

    +1 from me on

    all new code to just use EventClass::class

    .

    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 over 1 year ago →
    🇳🇱Netherlands bbrala Netherlands

    The 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 over 1 year ago →
    🇮🇹Italy mondrake 🇮🇹

    BTW - 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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024