0

I'm using Symfony 4 and there are custom event and subscriber, e.g. CustomEvent and CustomEventSubscriber. There is module which dispatch CustomEvent, e.g. CustomModule. And that module is using in the controller (ControllerA) and command (CommandB).

In other words possible two follow scenarios:

ControllerA -> CustomModule -> CustomEventSubscriber(CustomEvent)

Or

CommandB -> CustomModule -> CustomEventSubscriber(CustomEvent)

Logic in the CustomEventSubscriber little bit different depends on where was called CustomModule (ControllerA or CommandB).

How to pass that information to the CustomEventSubscriber?

I can add $context property to the CustomEvent and set it in the CustomModule. But in that case I should pass info about context to the CustomModule.

Or maybe I can use some global settings, e.g. container?

Or create two different event subscribers per CustomEvent, disable auto-wiring, and 'manually' init and add to the dispatcher in ControllerA and CommandB?

yivi
  • 42,438
  • 18
  • 116
  • 138
Andrey Lebedev
  • 141
  • 1
  • 9
  • What do you mean by "context"? Can you add a bit of code to your question, so it's clearer what exactly is what you are trying to accomplish? – yivi Nov 20 '19 at 10:22
  • In any case, all the relevant information should be included in the event object. – yivi Nov 20 '19 at 10:24
  • @yivi > By context i mean the same like in an API Platform normalization context [https://api-platform.com/docs/core/serialization/#changing-the-serialization-context-dynamically] context which passing with event from one subscriber to another. I've started to use GenericEvent with additional arguments. – Andrey Lebedev Nov 20 '19 at 11:44
  • 1
    The way to do this is pass whatever information you want within your event. Create your own custom event with whatever properties you need, and that's what your subscriber should expect. – yivi Nov 20 '19 at 11:45
  • Andrey, did the answer below helped you? Any feedback? – yivi Nov 23 '19 at 14:45

1 Answers1

1

No need to create globals, to pass around the container, or any other anti-pattern mechanism.

The obvious place to pass information from where the event is dispatched to where the event is handled, is the event itself.

Ideally, you would create your own custom event class, with whatever properties you need to perform the work down the line.

The custom event would be tailored to your application, and you could listen to those events specifically without having to check with getSubject() to see the listener should really handle that one.

Using a Generic is fine, although much less expressive. If you dispatch(new CustomerCreatedEvent()) it's immediately obvious what's going on.

That's the event your subscriber should listen to, and it would already contain all the necessary information gathered on the dispatching context.

yivi
  • 42,438
  • 18
  • 116
  • 138
  • Okey. What pros and cons to use custom event which extend Event vs GenericEvent? – Andrey Lebedev Nov 20 '19 at 11:57
  • The custom event would be tailored to your application, and you could listen to those events specifically without having to check with `getSubject()` to see the listener should really handle that one. Using a Generic is fine, although much less expressive. If you `dispatch(new CustomerCreatedEvent())` it's immediately obvious what's going on. – yivi Nov 20 '19 at 12:00
  • i meant i create CustomerCreatedEvent which extends GenericEvent and my subscriber expecting that type of the event. As i understand difference between extending Event and GenericEvent is additional event's parameters as array or object properties. – Andrey Lebedev Nov 20 '19 at 12:11
  • You should perhaps be aware that the GenericEvent has been depreciated in 4.3 and will go away in 5.x. Maybe take a look at: Symfony\Contracts\EventDispatcher\Event – Cerad Nov 20 '19 at 13:29
  • @Cerad Do you have a link for that deprecation? Can't find it, nor a `@deprecated` annotation on the source code. Would love to add that to the answer. – yivi Nov 20 '19 at 13:31
  • 1
    @yivi Look in vendor/symfony/event-dispatcher/Event.php to see the depreciation annotation. And since GenericEvent extends Event then GenericEvent is depreciated as well. The new event lives under vendor/symfony/event-dispatcher-contracts – Cerad Nov 20 '19 at 13:36
  • Thanks @Cerad, I was looking at the wrong class, obviously. – yivi Nov 20 '19 at 13:37
  • 1
    @yivi - Looks like I was wrong about GenericEvent going away. 5.0 was just released and GenericEvent is still there. It just extends from the Contracts\Event. I still don't see any compelling case for using it but it looks like it will be around for the indefinite future. – Cerad Nov 21 '19 at 13:34