Presenter Laravel Package

Getting Started

Install the package with Composer and check composer.json for the autoload entry that maps the namespace — the release notes reference Presentertrait.php, so start by reading that file end to end; it is the entire public surface of the package.

composer require <vendor>/<package>

First use case: take one Eloquent model or plain value object that currently leaks formatting logic into a Blade template, and attach the trait to it.

use Vendor\Package\Presentertrait;

class Order extends Model
{
    use Presentertrait;
}

Then call the presentation entry point from the view layer ($order->present() or whatever the trait exposes) and move the formatting code out of the template. Once one model works, roll the trait onto the rest.

Note for upgraders: as of v1.0.1 this is a trait, not a class. Anything that previously did class OrderPresenter extends Presenter must be rewritten to use Presentertrait; inside the class that owns the data.

Implementation Patterns

Trait-on-the-model (default). The intended usage is composition: the trait lives on the class being presented, so $this inside the presentation methods is the model. That means you can read attributes and relationships directly without wiring a constructor.

class Invoice extends Model
{
    use Presentertrait;

    public function presentTotal(): string
    {
        return number_format($this->total_cents / 100, 2);
    }
}

Keep presentation methods pure and side-effect free. They are called from views and API resources, often more than once per request. No queries, no writes — eager-load anything they need at the query level (with('customer')) rather than lazily inside the presenter.

Compose with API resources and Blade components. Treat the presenter as the single source of truth for formatting and have both InvoiceResource and invoice.blade.php call it. That prevents the classic drift where the JSON payload and the HTML page disagree about currency or date format.

Thin controller, fat presenter. If a controller is doing ->format('d/m/Y') or Str::title(...), that belongs in the presenter. This is the highest-leverage refactor the package enables and the one worth doing first.

Trait conflict resolution. Because it is now a trait, it can collide with other traits on the same class. Resolve explicitly rather than reordering use statements:

use Presentertrait, HasFormatting {
    Presentertrait::present insteadof HasFormatting;
    HasFormatting::present as presentRaw;
}

Testing. Unit-test the presenter methods against plain model instances built with Model::factory()->make() (no database) — the trait's reliance on $this makes these tests fast and dependency-free.

Gotchas and Tips

The v1.0.1 change is breaking on upgrade. If any of your classes did extends Presenter (or extends a package-provided presenter base), they will fatal once the class is a trait — a trait cannot be extended, and use on a class name fails. Sweep your codebase for extends referencing the package namespace. There is no deprecation shim in the release notes, so treat this as a hard cutover, not a soft migration.

Traits cannot be type-hinted. You cannot accept Presentertrait $presenter as a parameter, and you cannot instanceof check it. Code that previously type-hinted the presenter class in a service or a Blade component constructor must be reworked to type-hint the model itself, or to an interface you define and implement on the model.

Constructor and property traps. Traits cannot declare a constructor without clashing with the using class's constructor, and property declarations in a trait conflict with identical properties in the class. Keep state on the model; do not add properties to the trait.

parent:: inside a trait resolves against the using class. If the trait calls parent::toArray(), it silently depends on the host class having a parent with that method. This is the most common source of obscure "call to undefined method" errors after a trait migration — check every parent:: call when you upgrade.

$this ambiguity during the class→trait migration. Before, $this was the presenter wrapper; now it is the model. Any method that did $this->model->attribute must become $this->attribute. Grep for ->model — leftover occurrences return null silently rather than erroring, which is why this bug tends to surface as blank output in production rather than a test failure.

Static and self-referential calls break. self:: and static:: inside a trait bind to the using class, not the trait. If the old class had static helpers or constants, verify they still resolve.

Debugging. When a presented value comes back empty, dump $this inside the method first — confirming which object the trait is attached to resolves the majority of post-upgrade issues. class_uses_recursive($model) (Laravel helper) is the quickest way to confirm the trait is actually applied, and it will catch a missed use statement in a subclass.

Extension point. If you need to override behaviour per model, define a same-named method on the class itself — class methods win over trait methods — rather than forking the package. For shared customisation across many models, create your own App\Concerns\Presents trait that uses Presentertrait and adds your conventions, then attach only yours.