Laravel changed my mind about the Vue Options API

Published 11 months ago

The Vue Options API is a suboptimal way to organize Vue code.

At least, that's the opinion I've held since I first got my hands on Vue 3. I gave an entire talk about it at VueConf Toronto:

Recently though, I finally buckled down on learning Laravel, and the experience has changed my mind about the Vue Options API.

Laravel doesn't organize by logical concern

In my VueConf talk, I explained the difference between organizing by Vue options and organizing by logical concern:

Another way to think about this: options organize your code based on which Vue framework features it inherits, and logical concerns organize your code based on which bespoke app feature it supports.

In Laravel, I see a lot parallels.

When you're building a new feature in Laravel, everything starts with the php artisan make:model command. This command scaffolds PHP classes for your new database resource (usually the foundation of any major new feature), and it offers to create a bunch of stuff:

 ┌ What should the model be named? ─────────────────────────────┐
 │ Project                                                      │
 └──────────────────────────────────────────────────────────────┘

 ┌ Would you like any of the following? ────────────────────────┐
 │ › ◻ Database Seeder                                        ┃ │
 │   ◻ Factory                                                │ │
 │   ◻ Form Requests                                          │ │
 │   ◻ Migration                                              │ │
 │   ◻ Policy                                                 │ │
 │   ◻ Resource Controller                                    │ │
 └────────────────────────────────────────────────── 0 selected ┘

I just opt into everything the CLI offers, and I end up with a butt ton of random new PHP classes.

Each of these classes organizes your code based on which Laravel framework features it inherits, not based on the bespoke app feature it supports.

Even though I'm a newbie, I know a lot of this code is overkill. I'm sure a seasoned Laravel dev waits until their logic hits a certain level of complexity and reusability before separating it out into these new abstractions.

I haven't earned that intuition yet. It's much more important for me to focus on the fundamentals of backend web dev, like:

I'm still getting muscle memory for these rules, so it's been super helpful to have a scaffolded <Something>Policy.php file that screams, "Hey, I'm completely empty! Write some request authorization code!"

I'm viscerally, painfully aware that my code for a simple to-do list is split across 8 different files, each defining a single OOP PHP class using the inherited power of all of humanity's gods combined to do eye-wateringly incredible things, like make a new to-do with a fake name 🎉🎉🎉🎉🎉

But I did that on purpose, because Laravel abstractions make the underlying rules and patterns so incredibly clear. I can feel my brain learning how to pattern-match those same things out in the wild.

This is what the Options API gives to people who are new to frontend reactivity systems.

The Options API is a phenomenal teaching tool

It's easy for me to say that people should organize their Vue code by logical concern, because when I'm asked to build a new frontend feature, I'm privileged to intuit the reactive state, the memoized values, the state transitions, side effects, two-way data binding relationships, network calls, delicate effect timing, etc. etc.

I can do this because my frontend muscle memory is strong.

As I learn Laravel, I'm reminded of what it feels like not to have that muscle memory, to feel totally lost on where to start, and where to put code so that you can at least find it later when it inevitably doesn't work.

I now realize that my frontend muscle memory might not be as strong if I hadn't written code with the Options API. The Options API forced me to learn underlying patterns and explicitly acknowledge the Vue features I was using.

For Vue newcomers, the Options API is a way to get started, to just put your code somewhere so you can start to explore what great UI engineering is all about.

I will never use the Options API again, and I hope Vue will never stop supporting it.

My revised Options API decision tree

Organizing Laravel by logical concern

Please tell me this is a thing. I'm gonna need it soon.