EventSaucePHP
Prioritise generic type of payload over aggregate root
As per @shirshir's comment, not every use case uses aggregates but the payload is always present...
Having TPayload as the first type information would be extremely valuable for advanced static analysis without forcing folks to always pass the TId.
Sample use: https://phpstan.org/r/12e2b0f9-4689-4694-a0b9-ba7f8facf689
This is technically a BC-break, though...
@frankdejonge @markinigor what are your thoughts on this?
I think we can make it non BC breaking by providing a default of object.
Love this idea! Happy to help implement this if you'd like. Let me know if you want to collaborate on a PR or if you're planning to tackle it yourself.
That's exactly what I'm suggesting on the sample link.
However, people who are using Message<MyCustomAggregateId> will be hit when rolling out a version that expects that to be the payload, and have to change it to Message<object, MyCustomAggregateId>.
In theory the adoption is limited, so shouldn't be a huge impact buuuut I wanted to check before sending something in.
Let me know if you want to collaborate on a PR or if you're planning to tackle it yourself.
Thanks for the offer @markinigor. It's a pretty quick patch: https://github.com/EventSaucePHP/EventSauce/pull/242
(no need to rush things, btw)
@lcobucci while I understand for your use-case, this prioritisation makes sense, I actually think it's not the dominant case for people who use this for event-sourcing primarily. In the default case, I think it'll be common to hint only the aggregate ID whilst doing instanceof checks in consumers and what not. I'll have a ponder of it, but I think we should entertain the idea to append that type, rather than making the BC break.
@frankdejonge that makes sense and I'm quite fine with shifting the payload type to the end 👍
I'll apply the changes next week.
@frankdejonge 5 centuries later... I've just pushed the requested changes to https://github.com/EventSaucePHP/EventSauce/pull/242