Oh Dear is the all-in-one monitoring tool for your entire website. We monitor uptime, SSL certificates, broken links, scheduled tasks and more. You'll get a notifications for us when something's wrong. All that paired with a developer friendly API and kick-ass documentation. O, and you'll also be able to create a public status page under a minute. Start monitoring using our free trial now.

Simplifying presenters in Laravel

Original – by Freek Van der Herten – 3 minute read

In the Laravel template that we use to kickstart all our client projects at Spatie, I recently changed the way we handle presenters. Instead of using Jeffrey Way's popular presenter package we now use simple traits. In this post I want to give some background on that change.

In case you've never heard what a presenter is, let me give you a crash course. Imagine you have a User model with a first_name and last_name attribute and that you need to show the full name of the user in your UI. Sure you could just code this in a Blade view.

{{ $user->first_name}} {{ $user->last_name }}

But that becomes tedious very quickly when you need to do this in several views. You could solve this by adding a fullName function to your User-model:

namespace App\Models;

class User
{
   ...

   public function fullName(): string
   {
       return $this->first_name . ' ' . $this->last_name;
   }
}

Sure, that'll work, but when I open up a model file I do not want to see methods on how things should be presented in the UI. For one small function it's probably fine, but in a real life projects there will be many of such presentation methods. Putting them all in your model file itself will make it bloated.

A common solution is to place such methods in their own dedicated class: a presenter class. In the past we've used the popular presenter package by Jeffrey Way for our presenting needs. It's a very nice package, but there are some things that were bothering me. Using the package this is the way to call a method on a presenter in a Blade view:

{{ $user->present()->fullName }}

That present() part is kinda ugly. It would be much nicer if we could just call {{ $user->fullName }} in our view. But we don't want to bloat our model by adding a fullName function to it. This can be solved pragmatically by using traits. In most cases traits are used to dry up code duplication across classes. But in my mind it's perfectly fine to use traits to break down a big class in smaller bits. So in our case we could just make a separate presenter trait for each model that needs a presenter.

Using example above the UserPresenter could look like this:

namespace App\Models\Presenters;

trait UserPresenter
{
   public function getFullNameAttribute(): string
   {
       return $this->first_name . ' ' . $this->last_name;
   }
}

namespace App\Models;
use App\Models\Presenters\UserPresenter;

class User
{
   use UserPresenter;

   ...

}

Notice that we used an Eloquent accessor. In this way we can use {{ $user->fullName }} in a view. The model didn't become bloated with presentable methods. And the presenters-package can be ditched. Triple win! Let me know in the comments below what you think of this approach.

Stay up to date with all things Laravel, PHP, and JavaScript.

You can follow me on these platforms:

On all these platforms, regularly share programming tips, and what I myself have learned in ongoing projects.

Every month I send out a newsletter containing lots of interesting stuff for the modern PHP developer.

Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.

Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.

Comments

What are your thoughts on "Simplifying presenters in Laravel"?

Comments powered by Laravel Comments
Want to join the conversation? Log in or create an account to post a comment.

Webmentions

JuanDMeGon retweeted on 19th November 2019
JuanDMeGon liked on 19th November 2019
Mattias Geniar liked on 19th November 2019
José Cage retweeted on 19th November 2019
salierdev replied on 19th November 2019
"Putting them all in your model file itself will make it bloated." Exactly my thought last week, looking at one of my models ? Will do some refactoring tomorrow!
K. E. Olivier GBLEM liked on 19th November 2019
Demian liked on 19th November 2019
Andre Sayej liked on 19th November 2019
oluwajubelo loves VueJS ? liked on 19th November 2019
Clément Tessier retweeted on 19th November 2019
Mike Griffiths replied on 19th November 2019
Honestly, it works great as it is so I was reluctant to change it. I was kind of testing the water to see if the consensus was a "whoooa whoa, what are you doing?!". I'll take a look at the presenter package though, thanks all!
jiban liked on 19th November 2019
salierdev liked on 19th November 2019
Sebastian Rasch liked on 19th November 2019
Maarten Buis liked on 19th November 2019
이현석 Hyunseok Lee liked on 19th November 2019
?????? liked on 19th November 2019
Anani Oluseyi liked on 19th November 2019
Matt Stauffer replied on 19th November 2019
Agreed!!! Presenters and view models are also really great ??
Misbah ansori liked on 19th November 2019
बेद replied on 19th November 2019
How do you pass data to your pure vue (No intertial no other) components as a props using presenter ?
Clément Tessier liked on 19th November 2019
José Cage liked on 19th November 2019
Guus liked on 19th November 2019
Nathan Ganser liked on 19th November 2019
Madalin Tache liked on 19th November 2019
Martin Carlin liked on 19th November 2019