Laravel 9.31, weekly updates, and 🔥 tip
Couple fixes this week as well as some of the new features Taylor demoed during his Laracon talk. This brings us to Laravel 9.31.
Here are the highlights:
exceptmethod avoid faking for
Queuein #44106 and #44117
- Allow using a model instance in place of nested model factories in #44107
- UUID and ULID support for Eloquent in #44074
manifestHashto Vite in #44136
- Improve DX for fake batches in #44104
- Make Vite macroable in #44198
You may review the full branch diff on GitHub for a complete list of changes.
This version bump and update is automated for subscribers to a Shifty Plan. If you don't have one of those, be sure to bump your constraint and run
composer update to get the latest features.
Last week I went to a Laracon viewing party in Normal, Illinois. I've gone to this one several times now. So it was good to hang out in-person with my "normal" crew again.
I also had a few Human Shift purchases last week. Most were from relatively recent versions of Laravel. So I got them upgraded to Laravel 9 pretty quickly.
I spent Friday making tweaks to Shift after using the service myself. Most of these have become pretty superficial - wording changes in the PR comments or separating some of the automation into atomic commits.
This week I have a few more tweaks I want to make. I'll also continue my Wednesday live streams. This time adding some tiny features to Laravel's Stringable and HTTP Request classes.
Something we discussed during the viewing party was "how would you do X in Laravel". Of course I tend to stick as close to Laravel as possible. This is something I talk about in BaseLaravel where I don't fight the framework or mimic its patterns.
In one of the talks, they demoed using the repository pattern to hit an API. They pointed out that a repository doesn't have to be backed by a model or database. Totally agree.
I personally would take this a step farther. I would not use the repository pattern - as it is not used by Laravel. I would just use a model. Expanding on the speakers point, one that isn't backed by the database and therefore doesn't extend Eloquent's
I would store it under
app/Models. I would try to name my methods
save, etc. This way from the outside, it would appear as a normal Laravel model. Making it a familiar object to work with and simply an underlying implementation detail that it's backed by an API.