در حال بارگذاری ...

Introducing Ignition Error Page0:00

Next up, we have the new default error page in Laravel 6, called Ignition. Now, it was contributed by Phreak and Marcel's teams, and they've really done an amazing job. So let's take a look. Here, I have a fresh install, with a home route that returns Hello World. If I change that, let's return a view that does not exist, and if I come back, give it a refresh, now, rather than the typical Whoops page, you now see this. And again, there's a lot going on here. It's very impressive stuff. I think you're going to like it.

Smart Recommendations for Errors0:29

It's very impressive stuff. I think you're going to like it. So yes, immediately you see the most important thing. What was the exception that was thrown? However, in addition to that, when available, they will provide recommendations. So in this case, it looked around, it couldn't find any view that's similar to that. But it will let you know, well, at the very least, make sure that you created a view that has the proper extension. Let's tweak it a little bit, though. We know that out-of-the-box, Laravel has that welcome view, right?

Let's tweak it a little bit, though. We know that out-of-the-box, Laravel has that welcome view, right? Let's try to load that, but make a typo. Now, if I come back and refresh, Ignition has scanned your view file. It compared the view you're trying to load against all the existing filenames, and it found one pretty similar, called welcome. And it's letting you know, maybe that's the one you meant to load. And I assume behind the scenes, it's doing something like the similar_text function in php can compare two strings and let you know how similar are they. This one is 90% similar to that.

PHP can compare two strings and let you know how similar are they. This one is 90% similar to that. Or there's also a fun function called, what is it, Levenshtein, something like that. You rarely use it, but in cases like this, it can be really beneficial. Anyways, you'll see these recommendations all over the place. For example, let's try to select from a table that, again, does not exist. If I come back, we give it a load. Whoops, we forgot to import the DB class. And then again, and here we go. Here's our recommendation.

One-Click Automated Fixes1:55

And then again, and here we go. Here's our recommendation. Hmm, couldn't find that table. Maybe you forgot to run your migrations. Now, here's a cool thing. Many of the solutions can be run automatically with the click of a button. So when you click this, behind the scenes, it'll simply call php artisan migrate. It'll run your migrate command. Pretty neat. Now, if you're curious, take a look at the facade/ignition repo.

How Solution Providers Work2:15

Pretty neat. Now, if you're curious, take a look at the facade ignition repo. And if you visit the, where is it, source, you want the solution providers. So I haven't looked at it too much, but you can see for each of these classes, there's a method called canSolve. So this would determine whether or not the current solution is appropriate for the exception that was thrown. And I'm not sure, but I assume it's something like they iterate over all of these providers, and then they find the first one that can respond to the exception that was thrown. I assume it's something like that.

Okay, so now if I come back, we'll give this a refresh. And there we go. Did you mean created, which is also a method we could have called. In this case, not quite, but nonetheless, it's useful. Now let me show you one other thing I love. I'm going to instantiate a User, but notice that I haven't imported it correctly. So if I come back, here's what we get. Class User not found. Maybe you should import App\User. So in this case, Ignition is going to read Composer's class map list, and it's just going

Editor Integration and Extensions4:03

Maybe you should import App\User. So in this case, Ignition is going to read Composer's class map list, and it's just going to find out, all right, well, here's the class you tried to import. Let's try to find one with a base name that matches up with something in that class list. And if they find anything, that's probably what you meant to import. But here's where it gets cooler. If I scroll down, sure enough, I can see where the error occurred. And if I click on any line, it'll offer to open up my editor. However, we can extend Ignition with any number of first and third party extensions. So for example, if we take a look at Flare, which is the Sass counterpart to this, and

reload without ever having to return to your code editor. So let's take a look. So I can pull it in like this. So I will give this a run. And these extensions should automatically register themselves. So now let's come back and give it a refresh, and you'll see that the code editor has now changed. And even better, if we scroll up, hmm, maybe we forgot to import User. So we'll take care of that now. And then scroll down here.

So we'll take care of that now. And then scroll down here. Command S will update the file, and if I give it a refresh, we fixed the error. How cool is that? So now if I switch back to phpStorm, we can see those changes. Let's do another one. I have a Project model, and maybe I want to grab 50 items from that table. But once again, I'll add a typo here. Uh-oh, could not find that class. All right, so we take a look here.

Uh-oh, could not find that class. All right, so we take a look here. Oh, we made a typo. Save it, give it a rerun, and there we go. We fixed the error. Now again, if I switch back to the GitHub repo, here are all the solution providers that are currently available. And what's nice is they tackle many of the common things you'll run into, like an invalid route action, or a bad method call, or a missing import, or a view not found. And again, they all follow the same basic contract.

route action, or a bad method call, or a missing import, or a view not found. And again, they all follow the same basic contract. A method can solve, and then the solutions that it should provide. And yeah, usually you can see what it's doing is it inspects the exception method. It compares it against some kind of regex to determine, is this something that I want to operate on? And if so, a solution is offered. OK, one last thing here. Let's just manually log in a User here. Let's try to return a view.

Inspecting Request and Context6:41

Let's just manually log in a User here. Let's try to return a view. And if I come back to Chrome, give it a refresh. Of course, foo was not found. But of course, we have these additional tabs to inspect the request, the current state of the app, so the controller that was called, any route name, if one was supplied. In this case, I'm getting unknown because I don't have a name there. So I could say name, home, refresh. And now on the app tab, we'll see that there. Next, if there was an error thrown in the view itself, we would see this information.

And now on the app tab, we'll see that there. Next, if there was an error thrown in the view itself, we would see this information there. And I'll show you that in a minute. We have information about the currently signed in user. We have some information about the context, as well as a debug panel that'll show any queries that were executed as part of that request. So let's say now, if I come back, we did everything correctly. We loaded the welcome view. But welcome somewhere tried to reference a variable that doesn't exist.

We loaded the welcome view. But welcome somewhere tried to reference a variable that doesn't exist. So if I give that a refresh, once again, it'll let you know, hmm, I didn't know that user. We can take a look at it. Okay. It looks like there's an issue with the welcome view. There's nothing in the error back because we're not responding to a form. And of course, we can review the stack trace as much as we need to, to solve the problem. In this case, we'll do a default. Save it.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟