Working with Yii2 I faced a problem regarding the events "mechanism".

What is that problem:

You can only append or prepend handlers to Events. You can't decide yourself events' handlers priority.

I think this is a problem especially for developers that has previous experiences in other frameworks and also want to intervene in the request flow wherever they want to.

What I am going to implement:

So I decided to create a new Priority Queue Class based on SplPriorityQueue to handle events' handlers according their priority.

For the moment this implementation fully supports the append and prepend functionality as it is in order to support all current projects and core functionality.

However if you accept that change then we can step by step change that append-prepend approach in the near feature (regarding core implementation) and simultaneously all Yii2 developers can use handlers priorities in their new components.

Here:

Need different messages for cases:

• $event is null
• $event not object

For using in domain entities.

Logic: entity create events, but send their to dispatcher after save entity.

Example:

final class Post
{
    use EventTrait;

    public function setName(string $name) {
        $this->name = $name;
        $this->recordEvent(new SetNameEvent()); // Save event in entity
    }

    public function setAge(int $age) {
        $this->age = $age;
        $this->recordEvent(new SetAgeEvent()); // Save event in entity
    }
}

final class PostService
{
    public function save(Post $post)
    {
        $this->postRepository->save($post);
        $events = $post->releaseEvents(); // Get all events from entity and clear
        foreach ($events as $event) {
            $this->dispatcher->dispatch($event);
        }
    }
}

• Example of implementation

Mentioned in the articles:

• Decouple your Symfony application using Domain Events (EN)
• Проектирование сущностей предметной области (RU)

680194b#r38900256

What steps will reproduce the problem?

n/a

What is the expected result?

The attach function should be public anyway.

What do you get instead?

I can't call it any more from my project code.

Additional info

What steps will reproduce the problem?

What is the expected result?

What do you get instead?

Additional info

What steps will reproduce the problem?

What is the expected result?

What do you get instead?

Additional info

On add listener to ListenerCollection:
• static fn(string $event) => null; → must throw exception
• static fn(MyEvent $event) => null; → success added

In this test should throw exception.

Not a real issue more of a code formatting/style thing

What steps will reproduce the problem?

I see use function {php function name} is being used in multiple places.

I noticed in Provider it only imports one of the functions it uses.

What is the expected result?

Either all of the functions called out or none of them.

Other functions not called out:

• array_values
• class_parents
• class_implements

What do you get instead?

use function get_class; is only called out and the other functions aren't

Additional info

N/A

We should benchmark current getListenersForEvent implementation vs traversing all handles and checking instanceof and take the more performant one.

Hi,

Nice piece of code, i think i found a possible problem in php8. I didn't do the test but looking at the code i think in some very very rare case there could have a problem in the code if the php union typehint is used.

at this line of code, the object could be a ReflectionUnionType and not a ReflectionNamedType, so the getName() function will break.
https://github.com/yiisoft/event-dispatcher/blob/master/src/Provider/ListenerCollection.php#L85

Correct me if i am missing something.
Hope this help.

Instead of parsing each type of callable individually, we should at least test the cost of using Closure::fromCallable.
Using this would significantly simplify the code.

Reflection is used to determine event interface. It could be avoided by using cache based on \SplObjectStorage.

Before trying to implement that it is necessary to do a benchmark.

I'm using this library as a standalone package, and I ran into an issue: one of the listener methods does not have an event argument (which is currently needed by the library). This is because this listener needs to run a process at a specific stage of the runtime, but doesn't need any information provided by the event (whereas some other listeners for the same event need it). Adding the event parameter to the said method results in a parameter being unused, which is not acceptable (and reported by static analysis tools).

I completely understand the goal of this library and find it very interesting; however, the limitation I just spoke about is very problematic in that case, and could be the reason why some people may use another package than this one.

I would suggest to either add an optional $eventName argument to the attach method, or create a new basic provider with this feature which would allow the usage of the aggregate listener provider. I really think the second option would be the best one.

I'm ready to contribute if you tell me what you think of this issue, and what might be the correct solution to your eyes.

It's better to rename the ListenerCollection::add method to ListenerCollection::withListener because it's not clear that it's immutable

I use this package in my project #22

I find this package is refactored and I'm willing to adapt to my project.

My solution is making a public listener using ListenerCollection to subscribe to events.

And ListenerCollection is singleton so that the dispatcher use the same ListenerCollection.

But the snag is ListenerCollection changes every time when adding a new event handler, so the singleton pattern doesn't work(because of clone).

I'm curious why using clone when adding a new event hander?

At least, doesn't it affect performance?

Comment suggests we can't typehint because the parameter could be an array. But the function is private and only called once by a function that takes a callable type parameter.
So any argument that reaches getParameterType() will be callable.

Sometimes we use events in transactions, so they should not be dispatched before the transaction is successfully committed. As an example, imagine a user registration flow:

1. Validate data
2. Begin transaction
3. Write user to DBMS
4. Dispatch UserWasCreated event
5. Create a profile, catch an exception
6. Rollback transaction

The dependent services may have already sent the welcome email as a result of UserWasCreated event handling, but the transaction was reverted later.

That's why we use an Emitter – a thing that collects events but does not send them to a Dispatcher until flush() is called.

The implementation can be pretty dumb:

interface EventDispatcherInterface
{
    public function flush(): void;
}

final class Emitter implements EventDispatcherInterface
{
    private $dispatcher;
    private $events = [];

    public function __construct(EventDispatcherInterface $dispatcher)
    {
        $this->dispatcher = $dispatcher;
    }

    public function dispatch(object $event)
    {
         return $this->events[] = $event;
    }

    public function flush(): void
    {
        foreach ($this->events as $event) {
            $dispatcher->dispatch($event);
        }
    }
}

$provider = new Yiisoft\EventDispatcher\Provider\Provider();
$provider->attach(function (UserWasCreated $event) {
    sendGreetingEmail();
});

$dispatcher = new Yiisoft\EventDispatcher\Dispatcher($provider);
$emitter = new Yiisoft\EventDispatcher\Emitter($dispatcher);

$emitter->dispatch(new UserWasCreated($uuid));
// ... flow contiues
$emitter->flush();