[11.x] Updates mail notifications to use mailables #45943
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.


For a while now, it has been a small pain point that it's not possible to construct my mail notifications using mailables as I would do for any other outbound email from my applications.
I think the reason for this is that these are supposed to be simple transacational type emails, which makes sense. However, I do think there is some benefit in using mailables under the hood.
It actually is possible to use mailables as the
MailChanneldoes this check:However, the return type of the
toMailmethod suggests an instance ofMailMessageshould be returned. This will have an even bigger impact when this is a typed definition in Laravel 10 and I don't think it will be obvious to users that they can in fact return a Mailable object.So what is this PR doing?
This PR makes the
MailMessageclass extend from theMailableclass - in doing so, removing a lot of code duplication between the two. Moving forward, mail notifications will inherit all of the new goodies we add to mailables moving forward.It also means the
toMailmethod can have a return type ofMailableand folks can return whichever email they like if there needs are different from the default.Breaking changes
As far as I can tell, this causes a breaking change when using the
to,cc,bccandreplyTomethods as theMailMessageandMailableclasses handled these slightly differently. You can see this in the tests I have updated in order to suit the new format.If you think this PR is a good idea, I could probably update the
MailMessageclass to preserve backward compatibility, but my feeling was it's another place to maintain this functionality.I also had to rename the public
withmethod of theSimpleMessageclass towithLineas it conflicts with the mailable and has a completely different use.