Contrib.social

Brainstorm: Dynamic hook mapping?

Open on Drupal.org →
Created on 30 November 2023, over 1 year ago
Updated 1 December 2023, over 1 year ago

Sorry for being a bit vague in this proposal. I am still not sure where this will go.

Problem/Motivation

With the traditional hook system, and with Hux, the question of which method/function implements which hook is still all based on static information. With core it is a function name, with Hux it is an attribute. The same limitation also applies to the current attempt to bring hook attributes into core.

In some cases it could be useful to implement specific hooks based on dynamic conditions, which could be determined at container rebuild time, or even between that.

This can already achieved somewhat by providing a global static hook implementation, and then doing the conditional logic and dispatching inside that hook implementation. But this is clumsy and limited, and it adds a lot of unnecessary implementations and repeated checks.

Steps to reproduce

Proposed resolution

It would be interesting to be able to dynamically add hook implementations.
E.g. based on configuration we could have multiple instances of the same class, with different constructor parameters, to all implement the same hook but in different ways.

The list of dynamic implementations could be cached with cache tags (and contexts?) so that it will be reset when the relevant state or configuration changes.

A cached dynamic implementation is not just a service name + method, but a factory + parameters + the actual method. Or could it be a plugin?

Remaining tasks

User interface changes

API changes

Data model changes

🌱 Plan
Status

Postponed: needs info

Version

1.2

Component

Miscellaneous

Created by

🇩🇪Germany donquixote

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

Comments & Activities

  • Issue created by @donquixote
  • Comment over 1 year ago →
    🇩🇪Germany donquixote

    What about symfony events?

    Do symfony events allow this behavior?

    I am not quite sure.
    The event subscribers are determined on container rebuild time, mostly based on static information (static method getSubscribedEvents()).

    There is a method ->addListener() which is totally dynamic, _but_ it is not really suitable for the kind of dynamic implementations we are talking about. The method has to be called again every request before the event fires, which can be impractical.

    This said, I think whatever I am proposing here for hooks could also be implemented for symfony events, if we really want to.

  • Status changed to Postponed: needs info over 1 year ago
  • Comment over 1 year ago →
    🇦🇺Australia dpi Perth, Australia

    Does ✨ Dynamic hook ID specific attributes Active cover this? The idea is mainly the attribute can emit multiple ID's it wants to listen for. These ID's would be build on compilation, not as a runtime _listener_.

    I dont think I'd want or see the value in runtime listening, or basing it on various environmental/session based conditions. At least not something a wide-capture hook, e.g hook_entity_update vs hook_entity_TYPE_update could not condition filter itself.

  • Comment over 1 year ago →
    🇩🇪Germany donquixote

    Hi
    The idea here is about ids determined dynamically based on stuff like config values, but not based on per-request runtime info like current user etc.

    E.g. imagine a module like rules where each rule could implement a hook.
    Tbh I have not looked at rules module in a while, but I just did and it is interesting.

    https://git.drupalcode.org/project/rules/-/blob/8.x-3.x/src/EventSubscri...
    https://git.drupalcode.org/project/rules/-/blob/8.x-3.x/rules.module
    I see static-to-dynamic dispatching from hooks to events which looks quite wasteful.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024