Taking a class-based approach to views in Laravel.

Sam Jones — Sun, 25 Nov 2018 12:00:00 +0000

Note. this article was originally published on Medium on Mar 15, 2018.

I’ve recently been working on a simple Laravel package called Laravel Viewables that wraps up my approach to class-based views in Laravel. I use it in pretty much all the medium/large sized projects I work on.

For a while now I’ve wanted to write down my thoughts on why I take this approach and how others can benefit from it. Imposter syndrome has prevented me from publishing this sooner but I got there in the end! HI-FIVE to my fellow imposters!

When To Use Class-Based Views?

To be clear here unless you know you are going to need to extract views into classes then I don’t think a project should ever be started using this approach from the get-go. Class-based views can be implemented very simply during a refactor, when controller methods start to become bloated with dependancies that are specific to the view itself.

A great example of this would be an ecommerce application report page that involves sales revenue aggregation. Think about the separation of concerns; should the controller know (or care) about any of these things:

The name and location of the view file.
How specific view data is retrieved/calculated and…
…the names of variables the view is expecting to receive.

Personally, no, I don’t think so. It would be much more convenient if all this view logic was kept in it’s own class with it’s own dependancies, this is where class-based views can help clean up controllers and help manage complex views more easily.

Using class-based views reduces how tightly coupled the controller is to a specific view/blade file and shifts that coupling to a dedicated class. This reduction in coupling becomes more apparent when controllers have multiple methods that return views.

Again, to be clear, I’m not suggesting turning all views in class-based views, don’t over or pre optimised code for simple views with simple logic.

I’m Sold. How Do They Work?

Starting with Laravel 5.5 the framework shipped with a Responsable interface, implementing this interface required including a toResponse() method on the Responsable class. A new instance of that class can now be returned directly from a controller.

Adam Wathan put up a nice little example of a Responsable class on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-897836363885797376-8'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=897836363885797376&theme=dark" }

Ok, So What Are Viewables?

Viewables (as I named them) are built on top of the Responsable interface and build in functionality and methods similar to how Laravel’s Mailable classes work. They provide a more fluent way to build out class-based views.

The full documentation can be found here but I’ll re-refactor the above example from Adam’s example and sprinkle in some comments to show how it can be done.

These examples are fairly basic and overly simplified but I hope you can see how the use of class-based views can help clean up controllers and separate complex view logic into more manageable classes.

Let me know if this post has helped you or if you have any questions I’d be glad to try and clear things up.

Forem: Sam Jones

Taking a class-based approach to views in Laravel.

When To Use Class-Based Views?

I’m Sold. How Do They Work?

Ok, So What Are Viewables?