Things I didn't know Laravel could do

It turns out that there's a long road between "I have a book contract" and "I know everything there is to know in order to write this book."

It doesn't matter how much of an expert you feel like. It doesn't matter how much time you've spent learning and teaching. Across the board, every tech author I've talked to has described just how much they learned—had to learn—when they wrote a book.

I learned a lot in writing Laravel: Up and Running. And I want to share it with you.

I wanted to write a book you will like

I had two big fears when I first started writing Laravel: Up and Running.

First, I was afraid that I wouldn't have anything to offer other than what was already on my blog. That fear was quickly assuaged when I realized just how much there is to cover.

And second, I was afraid I was writing a book that would be helpful for beginners but useless for everyone else. Once again, this fear didn't last long.

There is as much content in this book that I had to learn as I wrote as there is content that I already knew. The amount of source diving I had to do, and test apps I had to write, to get this book right is incredible. For several chapters I spent more time coding and testing and reading source code than I did writing the actual book.

A few things I learned

No blog post could contain all of the new things I learned from writing this book. I've been using—and teaching about—Laravel for years, and I was still shocked by how many tools and helpers and features I discovered.

Here are a few that stand out to me that I had never seen prior to writing the book.

1. The Cookie Façade is one special cookie

Cookies are a little different than other similar tools—cache, session, etc.—in that PHP can't actually write them in the middle of a user request. Rather, they have to be returned along with the response.

That means that the Cookie Facade (and the global cookie() helper) doesn't have anything like Cookie::put() to allow you to directly set a cookie. Traditionally, we've created cookies and then attached them to the response using code like this:

Route::get('dashboard', function () {
    $cookie = cookie('saw-dashboard', true, 15);

    return view('dashboard')->withCookie($cookie);
});

But in writing the book I learned that there's a queue() method on the Cookie Façade (and only on the Façade, not the helper or the injected class) that you can use prior to the response, and Laravel's AddQueuedCookiesToResponse middleware will un-queue that cookie and attach it to your response after your route returns. So that makes this code possible:

Route::get('dashboard', function () {
    Cookie::queue('saw-dashboard', true, 15);

    return view('dashboard');
});

In this example it doesn't matter much, but in a longer controller method you might appreciate the ability to set your cookie earlier—or to even set it somewhere other than your controller, if you want.

2. Attaching files to emails is easier than you think

I always knew you could attach files to your emails, but figured it was something like "get the underlying Swift object and then perform fifty lines of magic to make it happen."

Nope. It's stupidly simple.

Mail::send('emails.whitepaper', [], function ($m) {
    $m->to('barasa@wangusi.ke');
    $m->subject('Your whitepaper download');
    $m->attach(storage_path('pdfs/whitepaper.pdf'));
});

It's also incredibly simple to embed an image directly into your email template:

// emails/has-image.blade.php
Here's that image we talked about sending:

<img src="{{ $message->embed(storage_path('embed.jpg')) }}">

Thanks!

Magic.

3. You can chain more Scheduler methods than the docs show

The docs show that you can chain a few types of Scheduler methods together to define the schedule your commands will run at. But it turns out you can chain any reasonable combination of times together.

This makes the Scheduler much more powerful that the docs let on. You can now do something like this:

// Run once an hour, weekdays, from 8-5
$schedule->command('do:thing')->weekdays()->hourly()->when(function () {
    return date('H') >= 8 && date('H') <= 17;
});

You can also write more complex schedulers in other classes, and pass them in with a Closure:

$schedule->command('do:thing')->everyThirtyMinutes()->skip(function () {
    return app('SkipDetector')->shouldSkip();
});

4. You can assert that a view gets passed certain data

This seems like everyone should know it, but somehow I had never stumbled across it. In your tests, you can assert that, if you visit a particular route, the view in that route gets passed data. So you can write a route like this:

Route::get('test', function () {
    return view('test')->with('foo', 'bar');
});

And then write this test:

public function test_view_gets_data()
{
    $this->get('test');
    $this->assertViewHas('foo');        // true
    $this->assertViewHas('foo', 'bar'); // true
    $this->assertViewHas('foo', 'baz'); // false
}

Get your free sample here, folks!

There is a lot more that I learned that I haven't covered here. Much of it will come through in the little details, which made it not as good of a fit for a blog post like this—but trust me, there's a lot.

If you want to check out the book itself, I have a free sample available on the site I've set up for the book: laravelupandrunning.com

Want to read more today?

Finally, if you already know you want the book, it's available for print and e-book pre-order on O'Reilly, and if you pre-order the e-book right now you'll get a free copy of the first 12 chapters, right out of my text editor, before they've seen the strike of an editor's pen.

Thanks for checking this out. I'm confident that, no matter who you are (except you, Taylor, and maybe you, Jeffrey), you'll learn something from this book. I've busted my butt to get this to be useful not just to people new to Laravel, but every member of the Laravel community, and I think y'all are going to love it.