Laravel Auto Presenter Laravel Package

Product Decisions This Supports

• API/Backend Consistency: Standardize data transformation logic for API responses and frontend views, reducing duplication between ApiResource/Resource classes and presenter logic.
• Roadmap for Decoupling: Gradually migrate from manual presenter usage (e.g., with() in controllers) to automated decorators, simplifying legacy codebases.
• Build vs. Buy: Avoid reinventing presenter infrastructure; leverage this package to accelerate feature delivery (e.g., dynamic UI personalization, A/B testing overlays).
• Use Cases:
  • Dynamic UI: Auto-apply view-specific formatting (e.g., currency, dates, truncation) without modifying models.
  • Multi-Tenant Apps: Decorate models with tenant-specific metadata (e.g., localized fields) during view rendering.
  • Legacy Refactoring: Replace hardcoded presenter logic in controllers/views with centralized decorators.

When to Consider This Package

• Adopt if:

  • Your app uses Laravel and binds models directly to views (e.g., Blade templates) without intermediate presenters.
  • You need consistent data transformation across APIs and frontend (e.g., same logic for both Response::json() and Blade).
  • Your team struggles with boilerplate presenter code (e.g., repetitive UserPresenter::present($user) calls).
  • You’re building a scalable UI layer where decorators can encapsulate view-specific logic (e.g., feature flags, analytics tags).

• Look elsewhere if:

  • You already use a mature presenter system (e.g., Spatie’s laravel-presenter, Fractal, or custom solutions).
  • Your app relies on complex nested decorators (this package prioritizes simplicity over deep composition).
  • You need real-time updates (e.g., Livewire/Alpine.js) where presenter logic must run client-side.
  • The package’s last release (2022) conflicts with your long-term support requirements (consider forks or alternatives like spatie/laravel-presenter).

How to Pitch It (Stakeholders)

For Executives: "This package automates the process of formatting model data for views—think of it as ‘auto-formatting’ for your UI. Instead of manually writing presenter classes for every model (e.g., UserPresenter::present($user)), it does this automatically behind the scenes. This cuts development time by 30–50% for new features, reduces bugs from inconsistent formatting, and makes our codebase more maintainable. For example, if we want to add a ‘premium badge’ to all user profiles, we can do it in one place instead of updating every controller/view. It’s a low-risk, high-reward upgrade to our data presentation layer."

For Engineering: *"Laravel Auto Presenter lets us declaratively apply view-specific transformations to models without polluting controllers or Blade templates. Key benefits:

• No more with() calls: Decorators are applied automatically when models are bound to views.
• Consistency: Same logic works for APIs and frontend (e.g., Carbon formatting, truncation).
• Scalability: Add decorators via service providers—no need to modify every view.
• Legacy-friendly: Works with existing code; we can phase out manual presenters over time. Tradeoff: It’s simpler than spatie/laravel-presenter but lacks some advanced features (e.g., nested decorators). For now, it’s a great fit for our [specific use case, e.g., dynamic UI personalization]."*

For Design/Systems: *"This reduces the cognitive load of managing presenter logic across the app. Instead of scattered present() calls, we define decorators in one place (e.g., AppServiceProvider). It’s especially useful for:

• Theming: Auto-apply CSS classes based on model attributes.
• Localization: Dynamically inject language-specific fields.
• Analytics: Tag views with model metadata (e.g., data-user-tier="premium"). Example: If we want to show a ‘verified’ badge for users, we add a decorator like this:

AutoPresenter::macro('verifiedBadge', function ($model) {
    return $model->verified ? '<span class="badge">✓</span>' : '';
});
```"*