Problem/Motivation
Core now has most of its hook invocations centralized to ModuleHandler, which allows this project to move invocations to a decorated dispatcher service rather than dispatching procedurally via .module files.
This is a partial proof of concept implementation which shows how the project can utilise these enhancements to core.
This will require that minimum Drupal version is 9.4. I suggest creating a new major or minor Drupal version of this project in order to responsibly go forward.
Invocations are moved from .module files to a ModuleHandler decorator, which offloads event creation to tag based factories. Ultimately most or all module files can be removed
Because of the scale of the changes required to satisfy this issue I've only gone ahead and implemented a small part of the project as an example. In case this is rejected. Also you may want to open separate issues to do address individual submodules work:
- Core submodule, partially implemented
- Field submodule, partially implemented
- User submodule, fully implemented
- Other submodules, fully implemented
With this work you can see multiple events can be dispatched per hook, events can be constructed in a special manner, events with return values are returned to the invoker, and alter arguments are passed by reference.
I personally don't use in this project, especially as I maintain Hux which is a good alternative to this project. During development of my contributions to the core issue useful to Hux, I identified that both of our projects could benefit.
The idea is the behaviour (input/output) does not change. There is only internal code optimizations and cleanups.
Remaining tasks
- Review viability
- Work out a plan for which version this should be implemented in
-
Migrate remaining hook implementations from .module files to Factory services.
core_event_dispatcher_themefield_event_dispatcher_field_formatter_settings_summary_alterfield_event_dispatcher_field_formatter_third_party_settings_formfield_event_dispatcher_field_widget_settings_summary_alterfield_event_dispatcher_field_widget_third_party_settings_form
User interface changes
API changes
New event factories
Internal tagged services
ModuleHandler decorator
Interface for event return values.
Interface + base for self event factory
Data model changes
Order of event invocation may change.
Issue fork hook_event_dispatcher-3277301
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
dpiDoesn't look like tests are enabled for 4.x
Comment #4
dpiComment #5
el7cosmosLoves the idea. We can continue this effort.
Test for 4.x branch now enabled.
Comment #6
el7cosmosI'm thinking to implement this in 3.x and keep support for core < 9.4
Comment #7
dpiNote there are some hooks that wont work with this code until Drupal 9.4.
See the list at the bottom of https://www.drupal.org/node/3000490
Until then you will need to keep the old hooks in .module.
Comment #8
el7cosmosYes, old hooks will still be maintained in .module file, check for core version and tag with deprecation, I'll try to push to another branch
Comment #10
el7cosmosTests are passed against 9.3 and 9.4. We still need to fix phpcs, phpstan, and phpmd violations.
Comment #11
dpiFor the PHPStan errors above.
The constructors for most of the events in this project could probably be made
final, as they are considered internal/private.public function __construct(->final public function __construct(-
Much of the docs included here has a bunch of new PHPStan data types. I'd suggest ignoring
Drupal.Commenting.FunctionComment.IncorrectParamVarNamandDrupal.Commenting.FunctionComment.InvalidReturn. But only ignore them if you plan to use PHPStan, as Stan provides the safety for you here.Comment #12
el7cosmosI introduce a plugin system instead to discover event classes.
Comment #13
el7cosmosComment #14
el7cosmosComment #16
el7cosmosThanks @dpi
Comment #20
dpiComment #21
dpiComment #22
singularo