Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not very clear in docs that it only works for dirty fields #14

Open
blite opened this issue Nov 2, 2022 · 3 comments
Open

Not very clear in docs that it only works for dirty fields #14

blite opened this issue Nov 2, 2022 · 3 comments

Comments

@blite
Copy link

blite commented Nov 2, 2022

I had thought from docs it would work for a created instance if the attributes were set properly.

@jpkleemans
Copy link
Owner

Hi, thanks for your comment. This is something I have been thinking about as well.

I'm not sure if that should be the default behaviour, because it is hard to check whether a model was created or updated. Especially in a queued event listener.

Perhaps I can add a special syntax to indicate that an event should also be fired on creation of the model (if the attributes were set properly). For example, in vue.js you have an option immediate: true to indicate that an "event" (watched prop) can also be dispatched directly at creation.

Maybe something like this:

protected $dispatchesEvents = [
    'status=shipped' => OrderShipped::class
];

Problem with this is that it introduces a new syntax that is not very explicit.

What do you think?

@blite
Copy link
Author

blite commented Nov 8, 2022

i would use same syntax

        static::created(function ($model) {
            $model->syncOriginalAccessors();
            $model->fireAttributeEvents();
        });

needs to additionally add checks for wasRecentlyCreated to the isDirty checks

ie

isDirty || wasRecentlyCreated

I think wasRecentlyCreated should work as the process that is queueing the event should be the same as the one that created the model, even if you defer object creation to a queue, well its then that queued job that creates the new event.

if I found this wasn't possible. I would just mention it in the docs that it works by monitoring dirty fields and you should manage create events separately.

@andreinocenti
Copy link

Hello,
Is there any news about this feat? Be able to fire the event on creation or update is something that I would use too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants