Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

Simplifying presenters in Laravel

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.

Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band.
  • propaganistas

    How would you go when you still need the raw database value in some view? Using $user->attributes['first_name'] seems rather cumbersome. In my opinion explicitly calling the present() method visually denotes that a “modified/parsed” value is returned.

    • If you like to see `present()` part in your views, by all means keep using Jeffrey’s package. I don’t think there’s a right or wrong here. It’s just a different approach.

    • I use $user->fullName() as a method. I can tell it’s a method because it has () versus $user->first_name.

      • amosmos

        You mean you don’t use an Eloquent accessor?

        • No, I don’t use accessors outside of the database fields.

  • Not sure why you used this approach since you stated.

    Sure, that’ll work, but I feel this kind of presentation logic does not belong in a model.

    Using a trait you pollute the class with the methods borrowed from the trait, you just write it into a different file.

    For how I understand them, traits does not help to separate concerns.

  • Pingback: How (not) to use accessors in Eloquent - murze.be()

  • Tibor Soviš

    Interesting approach for splitting class. Does this redefine SRP?

  • robjbrain

    Unrelated to the post, but what does “: string” do after the method name? I’ve never seen it before and i’m struggling to google it.

  • iboinas

    Hey Freek!
    Hmm, how do you deal with currency presenters?
    So that when u want $model->price on calculations, it doesn’t mess them up??
    Isn’t also a good time to implement the MySQL virtual fields?

    • Swaz

      I just prefix my presenters with the word present. So it would be $model->presentPrice, or $model->presentFullName. Then you never need to worry about messing up the raw data output, and it’s clear in your views that you are working with formatted data.

      • iboinas

        Nice one, thanks for the tip!

  • Jakub Kratina

    I use new class instead of a trait. UserPresenter with method fullName. And in the User class I add getPresenterAttribute and return new UserPresenter($this). Thanks to that I can write: $user->presenter->fullName