Presenter Laravel Package

Product Decisions This Supports

• Presentation layer: build vs. buy vs. do nothing. The real decision isn't "adopt hemp/presenter," it's "should we standardize a presenter convention?" This package is a trait plus a base class that gives models $model->present() and a class to hold display logic. Evaluating it is cheap; the decision it informs is whether formatting lives in models (accessors), controllers/resources, or a dedicated presenter.
• Architecture: keep formatting out of Eloquent. Supports the call to stop mixing currency, dates, name concatenation, status labels, and truncation into models and Blade templates — especially when one model feeds web, API, transactional email, exports, and admin screens with different shapes.
• Roadmap sequencing. Guides whether to introduce the presenter layer now (greenfield, before formatting sprawl) or defer until formatting duplication is actually costing us. Value peaks at roughly 3+ output channels per model; below that, the layer is overhead.
• Feature-level consistency. Enables delivering consistently formatted, localized display fields ("member since," human-readable status, initials, money, relative dates) across customer-facing UI and support tooling — a small but real driver of support-ticket volume and UI inconsistency bugs.
• Representative use cases: admin/back-office screens, notification and email templates, CSV/PDF exports, CMS-style content, and any Laravel app with a display surface distinct from raw persistence.
• Strategic weight: low. Presentation plumbing is table stakes, not differentiation. Keep this as an engineering-led convention decision; do not roadmap around it or present it as product value.

When to Consider This Package

Consider it when:

• You run a Laravel/PHP app where several models need shared display formatting across web, API, mail, and exports.
• The team wants the smallest possible version of the presenter pattern — MIT-licensed, single-purpose, readable in full — rather than a heavier view-model or DTO stack.
• You want a migration target for an app that already has scattered formatting logic and no convention.
• You're comfortable treating it as a pattern to vendor, not a dependency to depend on (copy the trait and base class into app/Support).

Look elsewhere when:

• Ecosystem validation matters. 247 stars and 0 dependents means effectively no production track record; single-maintainer bus factor and infrequent releases (last: 2024-03-22). If dependency policy requires community-vetted packages, this fails review.
• You need typed DTOs, consistent API serialization, or OpenAPI-backed contracts — use Laravel API Resources or spatie/laravel-data, which have larger communities and active maintenance.
• Your stack is Livewire- or Inertia-heavy, where component props already define the presentation boundary; presenters become a redundant third layer.
• You're in performance-sensitive hot paths where magic __get proxying on every attribute read can't be justified.
• The app has only one output channel per model — accessors or Blade components are simpler and sufficient.

How to Pitch It (Stakeholders)

Executives: This is an internal code-organization decision, not a product bet. It has no direct customer-visible impact; it either makes formatting-driven bugs cheaper to fix or adds a layer we don't need. Cost of trying is near zero: MIT license, tiny pattern, trivially replaceable. The question to fund is "team convention," not "vendor risk." Recommend a one-model pilot with a go/no-go in a sprint, not a platform initiative.

Engineering: hemp/presenter gives models a present() method returning a presenter class that proxies attributes to the model and exposes display methods — keeping currency, date, name, and status formatting out of Eloquent and out of Blade, and letting one model serve HTML, JSON, mail, and exports in different shapes. Caveat: 0 dependents and a single maintainer, so vendor the trait and base class rather than adding a Composer dependency — it's small enough to read and own in an afternoon, with attribution. Recommended stance: pilot on one model with multiple output channels; if duplication drops, standardize internally. If the actual requirement is typed DTOs or explicit API contracts, choose Laravel API Resources or spatie/laravel-data instead and skip this. Decision owner: engineering lead. Product's only stake is knowing which output surfaces must stay in sync and who owns formatting consistency when a field changes.