Latest / The Laravel Podcast / Routing and Blade, with Caleb Porzio

Transcript

Routing and Blade, with Caleb Porzio · The Laravel Podcast

• Matt Stauffer: Welcome back to Laravel Podcast, Season 4. Today's guest is Caleb Porzio, the creator of Livewire, Alpine, that one Sushi, lots of good stuff. Stay tuned. Matt Stauffer: All right. Welcome back to the Laravel Podcast, Season 4. I said last time, I said every single topic is an episode. Every single episode is a single topic. And we are talking about something where we want to talk about an important and key aspect to Laravel in a way that is really helpful and friendly to newcomers, but then also is interesting to people who've been around for a while. Matt Stauffer: And so today we're going to be talking about routing, blade, and blade as templates in Laravel, if you're not familiar. So really all the front-end stuff, where you take the request from the user and you send it back out. We're ignoring all the front-end JavaScript and all that, which is funny considering who I have as a guest, but it's all the more inherent native Laravel front-end stuff. Matt Stauffer: Before I say anymore, I want to introduce my guest. This is Caleb Porzio. So we've got Livewire. We've got Alpine. We've got that thing of stickers you did. I don't know what else. What else do you do of things and what did I miss? Caleb Porzio: That's funny. Matt Stauffer: But that was like the first big public thing you did after you left Tighten, right? Caleb Porzio: Thank you. Yeah. Matt Stauffer: So anyway, say hi to the people, introduce yourself the way you would normally introduce yourself. Caleb Porzio: I'm terrible at introducing myself. I'm Caleb Porzio. What do I say now? I say it like open source maintainer now. Matt Stauffer: Yeah, that makes sense. Caleb Porzio: Laravel guy. But yeah, I created and maintained Livewire and Alpine. I used to work at Tighten, your agency. Yeah. And I work on other small things, but that's my thing. Matt Stauffer: Yeah. So this is basically nepotism, right? Like I'm just bringing on all my friends and Tighten ETS and everything like that? Caleb Porzio: Yeah, well I figured I have a better chance of getting on now that I left Tighten. Matt Stauffer: Now, that I'm curious to unpack. But you know what, actually, that's a good point because it's less nepotistic because I could have totally loaded the last season of Laravel podcasts with just all the people at Tighten and had a really fascinating podcast, but I didn't. So you're right. I feel less pressured not to bring somebody on once they don't work at Tighten. That was your plan the whole time, just to get on the podcast? Caleb Porzio: That's why I quit. Matt Stauffer: Nice work. You did the job right. Caleb Porzio: Yep, had to free up the space. Matt Stauffer: I love it. Okay, so Caleb has... So I want to really quickly introduce those two things because they are relevant, but then I want to talk a tiny bit of history between you and me talking about the front-end and why I think that you were really the right person for this. So Livewire, I'm going to tell it in my way and then you tell me what I get right and wrong, that's my favorite part of this podcast, is people telling me what I get wrong. Caleb Porzio: I love it. I also hate explaining Livewire. Matt Stauffer: Yeah. All right. So Livewire, I've never actually done this before, Livewire is a combination of a Laravel tool and a JavaScript front-end tool that worked together with each other. So you install it once, you're not going to use it just in JavaScript, you're not going to just in Laravel because it doesn't make any sense. It is a tool that is designed to basically... So if you're familiar with PJAX or, gosh why can I never remember the name of the Rails one? Caleb Porzio: Turbolinks? Matt Stauffer: Turbolinks. The idea behind those tools, I think, would be helpful to introduce. Turbolinks and PJAX, the idea is that let's say you have an entire web application and every time you navigate between pages, the header stays the same, the left nav stays the same, and the footer stays the same, but there's this like middle div that you probably named content or something like that, that changes from page to page. And so in Turbolinks and PJAX, you basically point PJAX, return point Turbolinks, which is basically the branded name of Rails version of PJAX, at that div. And you say, when somebody clicks a link, let's say they go from the homepage to the about page, instead of actually doing a full server refresh, go using JavaScript, get the contents of the next page, the about page, and then swap out only the contents that div, that content div, with the content div from the about page. And then also use push state to change the URL in the browser. And there're some niceties around it. Matt Stauffer: So you can make the request in a way where the only HTML that's actually transferred over is just the HTML from that div, rather than the whole div. But in the end, that's functionally what's happening, is that JavaScript is making a request, it's getting that new internal content. But the biggest thing is not only is it not transferring and re-rendering the sidebar and the header and the footer, but it's also not having to completely re-request the entire HTML structure from scratch and not having to get JavaScript and CSS or any of the shared images and stuff like that. And so it feels fast like an SPA, but it also feels like a browser thing. And one of the cool things about it is let's say you're on this about page and you hit refresh, then it gets that about page directly from the server. And then again, it's perfectly server-rendered, but then every future navigation from there is replacing just the content and that div. So that's what PJAX and Turbolinks are like in general. Matt Stauffer: So imagine that, but instead of this thing where you're just kind of stuck with that div, you don't get any interactivity and one of the difficulties for a long time about dealing with Turbolinks and PJAX has been, what does it happen when you interact with the view? Matt Stauffer: You have interactive view components on a PJAX page and then the PJAX page changes. How does that change the view state? And there's a lot of complexity there. So imagine instead a circumstance in which there was an inherent integration with your Blade components, which we haven't talked about yet. So this is confusing to talk about first. So sorry, newcomers. I'll try to get past this part quickly where basically your Blade components have knowledge and understanding that just that individual Blade component can be interactive in that way and can be recycled in that way and can have their view regenerated that way without the entire page having to refresh. So you get this level of interactivity and updated information from the server and little mini JavaScript requests to the server for individual pieces of the page, would that piece of the page is like the 10 posts in your paginated table, or whether that is the widget that's showing like the up-to-date stock ticker for the last 10 minutes or whatever else it ends up being. Matt Stauffer: You have these little, little pieces of the page that can also nest within each other. And the responsibility of Livewire is to basically allow you to write very simple, purely PHP components that take the responsibility among themselves of tracking their own state. It's sort of like a view type situation, but also handling the responsibility for when they should be doing those updates. So, whereas PJAX is more, just broad, like you got this content div and when somebody clicks the link, it changes them to a different piece of content in the content div. Matt Stauffer: Livewire is like that, but so much more integrated with Laravel where each component is having its own state and its own set of responsibilities for managing its own knowledge of whether it needs to be for refresh or not. So it's much more like a reactor, a DOM type situation where components have their own state. And they're responsible for like diffing the DOM between old version new version, but you're not writing JavaScript. You're writing PHP the whole time and you're really writing Blade. If you know, Blade, you basically can understand how to write Livewire. That's how I think a live wire, Caleb, how'd I do. Caleb Porzio: Yeah, you did pretty good. It's super tough. It's a super tough thing to explain. Even though it's fairly simple in practice, at least it, on the surface, the way I explain it for, without using, without getting into the internals of it, the most like basic explanation I generally give is the first magic you encounter with Livewire is that you can execute backend PHP codes, the picture of PHP method, like a controller method or something where normally, if you want to execute that code, you have to make a full request with a form post or visit a link with a URL. Or if you're using Vue or React, you would make an Ajax request to an endpoint or Livewire gives you this magic where if you have like a button tag, you can add wire click and then specify the name of a method that lives in the backend. Caleb Porzio: That's what clicked for me. Cause it Livewire takes a lot from Phoenix.LiveView, which is a similar framework in a similar ecosystem. And that's what clicked for me. Like I don't speak elixir, which is what LiveView is in, but it's, once you see that cycle, when you just see that, that one button tag with wire click in Phoenix world, it's Phoenix click wire click and then the method. And then the other screenshot is a PHP method with that same name. And you go, wait a minute, somehow clicking this button directly, execute this method name, and then everything re-render is and does its thing without doing a full page refresh and whatnot. So that is pretty much the way that I explain it on a surface level of it's this magical thing that allows you to execute PHP code from the front-end, at least that's how it feels. Matt Stauffer: Yeah. And that's why I think that you're the perfect person for this. So for those of you who are newcomers and you're like, I don't even know what Blade is, let alone with all this stuff is, the context here is basically Caleb has been writing JavaScript based tooling to allow people to have of the value of JavaScript without leaving PHP. And that's the really, without leaving a specifically Laravel Blade. And that's, that's a lot of, what's really cool about it. And that's one of the reasons why Caleb's on for this call. He also wrote Alpine, which is a super, super, super light. Like if you were to imagine Vue and I'm sorry to use Vue as a comparison, but you would've imagined Vue without all the heaviness of like everything having to be components, if you use Vue just as single components on the page, it's much lighter than something like an Ember or React where you kind of have to do the whole deal. Matt Stauffer: Well, this is even lighter than that. You're using really simple decorations by just adding basically tags to your HTML. That automatically makes it like a couple of lines of code and everything's interactive and you know, you're toggling state and tracking state. It's obviously not meant for single page apps or something like that, but for minor interactivity or medium interactivity on front-end stuff, it's a really nice decoration again. How'd I do on that? I don't think I was as good as it's going on that one. Caleb Porzio: That's an easier one to explain. Matt Stauffer: Good. Cool. So Caleb has thought a lot about this and the reason why I originally thought Caleb for this topic, which is actually, before I talk about that... No, I will go there. The reason I brought Caleb on this is because Caleb and I for a long time had been, at Tigthen, had been a part of conversation around what does front-end, the ideal front-end look like for people who build the type of apps that Tighten does. Matt Stauffer: And we build very complex, robust, nuance things, trying to use the simplest possible technology for the sake of ease of creation, ease of modification longterm, ease of maintenance for whoever we're handing the project off to. So we don't want to pick the coolest hottest thing because that's often also the most costly thing to implement and often the most difficult thing for them to either hire for in the future or for their programmers to work with. So we want to use the thing, that's the closest to kind of like the core. And so we would often find ourselves in situations where someone would say, well, that's obviously Vue SPA or React SPA. And we say, oh, how can I do this in Blade? Or someone would say, well, I just instantly begin my project by writing a Vue SPA and then API, that's just it. Matt Stauffer: And we would say, oh, I always begin my project by writing it in Laravel's basic stuff and just add the JavaScript when I absolutely have to. And so Caleb and I are, we're very often on kind of like team, at least the beginning we weren't. Right? But I think we quickly coalesced on the same team, keep it in Blade as much as possible, keep it in Laravel as much as possible. Caleb Porzio: It's Team Vue and Team React that those were the brands teams. Matt Stauffer: Yeah, that's definitely true. Caleb Porzio: One day I was like, wait a minute, I'm actually Team Blade. Matt Stauffer: Yeah. And I had unknowingly been on Team Blade, but I thought it was, I think I kind of thought it was just cause it's an old man, but I think we realized in conversation that we were like kind of Team Blade and we were owned our alone little space. And then after leaving Tighten, Caleb built Livewire, which to me really kind of put Blade in the space of, it's not like reacting to you in Blade. Obviously they're not exactly the same thing, but are... Sorry, I feel in Livewire, but Livewire provides a lot of that kind of like front-end interactivity without having to leave Blade, which I love. Matt Stauffer: And so that's, among other things, the fact that he's just very knowledgeable. I think that's one of the reasons I really got excited to get Caleb on here is because he thinks a lot about working in the front-end and working well with Laravel and Blade. So today's topic is about two things. It's about routing and views and we're actually going to jump straight into routing first. Caleb Porzio: Okay. Matt Stauffer: And so what I want to say with the routing is there, is because I want to start there for two reasons. I think the first one is because I think that Laravel routing is the first place that every app hits, that's not technically true. You got middleware and stuff, but like for the average development experience, routing's the first thing you hit. And second of all, routing serves two things. One of them is to parse the incoming request and the other one is to pass information off to Blade technically or APS or whatever. Matt Stauffer: So let's just start with routing in an HTTP MVC app or routing in Laravel. How do you describe how routing works and what it's doing to a five year old or in the simplest way possible. Caleb Porzio: So I have a surprise for you. I read this in the little sheet and I thought, I know a couple of five-year-olds, my nieces and nephews. Matt Stauffer: Did you try it with a five-year-old? Caleb Porzio: I'm just going to call my nephew up, Sammy. He's four, almost five. Matt Stauffer: Close enough. Caleb Porzio: And my brother-in-law, his dad, is a programmer and sort of, he's Salesforce, but he knows Laravel a bit. So anyway, I got him on the phone right away. I recorded the call. So you can put it in if you want or not. Matt Stauffer: Yes. It's going in here. Right. I cut out like a chunk, just cut it in right here. Caleb Porzio: There's full permission to put it in here. I think it would be cool. But, I think my first responses is that you need to change the age range of that question. I don't think you need...whatever. Matt Stauffer: You can go for like seven or eight, maybe. Caleb Porzio: Okay, so I do the five-year-old and I start, Sammy, I'm going to misquote it because you're probably going to show it. But anyway, I'm like Sammy, so basically I very soon, I get to the question, "Sammy, do you know what a computer is?" And he goes, "I think I've heard of it". Matt Stauffer: Oh God. You're like, "I'm in trouble." Caleb Porzio: You got any iPad with your mom. And then we started going to like the iPad or whatever. So I quickly realized, I just got to save face and be like, "Thanks for helping me out, Sam... Good job". Matt Stauffer: That's fantastic. Caleb Porzio: "Can you put your brother on the phone?" who's seven and... Matt Stauffer: Oh, perfect. Caleb Porzio: So I get Danny on the phone and now he knows what a computer is and he's even expressed ambition and becoming a programmer someday. Matt Stauffer: Okay. All right. Caleb Porzio: And he, so the conversation was a little bit better, but I was explaining it through basically, I quickly found that his experience with the Internet is really answering like fun, like Buzzfeed type quizzes with his mom. So I use that as a platform of like, okay, so you're on the quiz. That's a website. Okay, Dan? Yeah. Okay. That's a website. Now when you click a button in the quiz, what happens? Well, it shows you the answer. Okay. How does it know that? And so I was like, Danny, I just need to get you to the place where I can ask you what is routing in Laravel and you tell me, so anyway, you'll hear it. But... Matt Stauffer: Yeah. Caleb Porzio: I'll say that. I was sort of, I thought it would be a fun experiment and it was, but I think we even might need to go to like 12 years old. Matt Stauffer: Yeah. Caleb Porzio: I need to bump the age to be used. Matt Stauffer: Let's go for 12. Give me 12. Imagine I'm your 12-year-old cousin then. Caleb Porzio: Yeah. Well, I mean routing. Hm. Honestly, okay. The actual 12-year-old version is that, when you go to a website, you put something in the URL bar, what is the URL bar? Little white box at the top of your browser. What is a browser? Okay. We're back in the loop. Caleb Porzio: You put the Internet, you put something in the browser, you have the website and then slash and then thing, and then slash. Those things are like looking up files in a folder or something. You're putting a key in and you're getting a value out. The routing layer routes whatever, a route is basically a map. It's a link from that key to the page you want to show the user. I mean, that would be my 12 year old definition, I think. Matt Stauffer: Yeah. Caleb Porzio: But I think I have a better definition because most people listening this aren't 12. Matt Stauffer: That's true. Caleb Porzio: I think this is an important thing to, I try to put my newbie hat on to go back to how I felt when I was encountering all this stuff for the first time. Y. Matt Stauffer: Yeah. Caleb Porzio: And when you start learning web design, you realize, whoa, I can create an HTML file with Notepad, double-click it and open it in my browser. Caleb Porzio: That URL bar can point to files. Then you learn, you can put that on a website. I could host it on a server. And now it's /about.html or /a different thing. You're linked to different pages. And then you learn PHP, which is like HTML, but it goes through a program first that changes it in some meaningful, programmatic way. So it might be about.php. Well, anyway. Okay. So that was like me learning PHP. Caleb Porzio: But then when I encountered, I think Yii or CodeIgniter, I forget which one was first, but one of those frameworks, when I encountered them and seeing that the URL bar became something different where like the routes, they weren't files anymore. It wasn't .PHP. And that threw me for a loop. It was, /just a word, like admin, /user/1/show. Caleb Porzio: I was like, wait a minute. So this mapping, this file thing, you're just faking it? You're like intercepting it somewhere and saying, let's fake it. And so, anyway, I think that's worth mentioning or like going back to that route, that that was a big realization for me is that, routing is like, pretending to be a file. It's like, you call a file. And the server's like, I know you want this file or, it knows how to respond by calling one file index .PHP and deferring the file choice to you in the router. You could create a route called about.php., you could literally do that and you could, would return whatever you want. Okay. That's how I explain. Matt Stauffer: I think it's a fantastic point. I love that. I love the pointing out, so if you were to upload a Laravel application to your server and had not taught that server, that every single request in the server, no matter what the URL should go over to public/index.PHP, you wouldn't have a functioning Laravel application. Right. And so it is depending, go ahead... Caleb Porzio: It's important to recognize what layer does that and that's the NGINX or Apache layer. Matt Stauffer: Or Apache or whatever. Caleb Porzio: ...which is your server program, which is something that again is confusing at first. But that's the layer that handles, really handles the magic. And then Laravel just has an index.php file and is able to... Matt Stauffer: That's a great point. Like the most important piece of the routing happens before your Laravel app even gets touched. Caleb Porzio: Exactly. Yup. Matt Stauffer: Yeah. So you got an NGINX configuration file or a.ht access or whatever else. There's a directive in there that somewhere. And usually it says if a folder's a folder show the folder, if a JPEG exists or if file exists or something like that, show the file. Otherwise, basically it's like a fallback. It says, if this thing that somebody just typed /about or whatever, doesn't exist, then serve index.php and give it all the parameters that it needs. So basically index.php says, oh, I'm being called it spins up Laravel, and then Laravel has the ability to say now, what were you called with? Oh, /about/ well, let's go look that up in our routing stuff. So then we get into Laravel routing. I think it's a great point. So Laravel routing. So, just really quickly, how is Laravel routing structured and is it similar or different to other routing you've seen, like, if somebody is just either not familiar with how to define routes at all, or if they've done it elsewhere, like, what's your experience there and like how it's similar or different or what's new or whatever. Caleb Porzio: Yeah. So, I guess what it looks like in Laravel, let's start there, in Laravel currently, there's a folder in your root project called routes/web.php. So web.php is the first place you start where all the routes are listed and you write a route with route and get and whatever the name. And again, it's this map. It's like routegetpost, get means, get requests. Like you're viewing a page, you could do a post request. Like you're sending a form, routget post and then you're returning a view, which we can get into later, which is some HTML with magic or whatever you want or returning JSON or something like that, the way it differs...Like I said, I got into CodeIgniter before Laravel I know you were in a CodeIgniter before Laravel and CodeIgniter does have the concept of routes, but it's almost secondary. Caleb Porzio: It's like, am I right in saying that CodeIgniter Intuit's if you do like post slash show, there's some system, some convention that it will auto look-up the method in a controller. So really you're not in coding on, you're not thinking of routes in terms of, what am I going to name? This route will be post/id, you're not thinking of that. You're thinking I have a post controller, a show post controller with a show method, and then you, you layer the routes accordingly. So routes are kind of magic for, and it's the same for rails. So I looked up routing and rails and I thought this was the case. And it is the same that like similar to CodeIgniter by default, it's the convention of automatically looking up your controller and then your method based on a route like intuiting, the method that you're running from a controller. Caleb Porzio: So anyway, this was something that when I came to Laravel, I was really jazzed about, I don't know, because I love it. It's almost like, wouldn't you want convention over configuration or something, but really in Laravel it's just, you go to one file and it's all laid out. It's all there. Every entry point in your application is in one file. And that is like a lighthouse in the sea, you're sailing along. And like, you can just see the lighthouse, you go back to that and you can always trace a thread through your application, back from web.php Matt Stauffer: I love that point because Laravel is often known for being kind of like convention over configuration. Like if anyone's not familiar with that phrase, it basically just means, by default, there's going to be the way things work and you can change it, but you don't have to set everything up every time. There's a lot of default conventions so that every Laravel app operates the same way. And you don't have to start every app you ever build by making decisions, because most of those decisions are made in the conventions. And so it's interesting that in this particular space, like there's other people that have more conventions. And interestingly also, Laravel had more routing conventions in the early days and they've really been discouraged because we kind of got bit by them a lot. Matt Stauffer: And that's one of the things I think I like about the most about like Laravel magic and Laravel conventions, is that like we have had some conventions that have gone away because they were difficult. And one of them was people would map an entire like segment to a resource controller or a controller or whatever it was the other name for it. But basically it just says any, like if you were to map something to /posts and you had a post controller, you could set a definition in the routes file. It says everything under /posts goes to this controller period. And we've kind of as a community, primarily stop using that because it's so many, it's bitten so many people, so many ways where like, don't do that anymore. So we've actually moved from a more magical... Matt Stauffer: You can, resource routes... where there's two of them, there's resource routes, which is just like the index show, whatever. But there was another one that was like everything. I can't even remember the name. Cause it's so long. Yeah. It was like, I can't even, it's been so long since I did it. Hopefully I'm not making that up, but I'm pretty sure. But even with resource routes, we still tend to say don't use resource routes or controllers, like actually define the whole thing. I have less trouble with it, but still, I think it's a little bit more likely for someone to not find the lighthouse because the lighthouse was saying wide by a resource controller and just know, just map the thing. Now I'm very curious, am I making that up or is that true? I think there was a global wizard, one word, but now maybe I'm just over-complicating resource routes. So anyway, routes/web.php, you mentioned both what it is and also how it's different to some other routing. Matt Stauffer: So basically, we often talk about routing being the traffic cop. Although we also say sometimes the controllers are those and I guess it's a good note that you said, which is controllers are very often a piece of the routing cause routing is not just route/web.php. It's also what takes something in there and sends it over to the end result. And man, I feel like we could have a whole episode purely about the process of taking an input and generating output and what types of different outputs can you return and how are they converted... Caleb Porzio: That's like replication, that's everything. Matt Stauffer: Yeah. And I was like, maybe let's not go there the whole way, but there is a good note, which is that like, so you were mentioning that it's a map and anyone who's not familiar with the map and programming, it usually just means like, if you were to imagine like an associative array or a key value of whole bunch of key value pairs, the keys on the left side, it's sort of like the thing that using the look something up and in the right side, it's the value that you're going to get if you enter that key, like that's kind of what we often mean when we're saying maps in JavaScript and stuff like that. Caleb Porzio: A legend is probably a better metaphor for that. Matt Stauffer: That would be a better terminology. Yeah. Caleb Porzio: But yeah, for something like, that is one of those words that now is second nature for me, but I remember being yeah. But that, because it's used in very specific ways, like a lot of program languages have maps as a data structure. Matt Stauffer: As an actual data structure... Caleb Porzio: But then, there's like, look up maps, there's just mapping all that stuff. And it's good to clarify that in my mind, mapping just means relating a group of things to another group of things. Matt Stauffer: Yeah. A whole bunch of inputs to whole bunch of outputs. Yeah. One to one. Caleb Porzio: Yeah. Matt Stauffer: Usually. So what he kind of means is like, if you imagine the routes file that it's going to be look ups, which is the router a definition of a wild card for a row. And then the thing that, that maps to, and usually the thing that maps to is going to be a string, defining a view name, it's going to be a string defining something you also, you should redirect to, it's going to be a closure or an anonymous function that actually is the body of that route or a controller method, which is also going to be a function that's the body of that route. Matt Stauffer: So basically at some point you're defining other than the shortcuts of the view or the redirect, you're usually mapping a single URL or URL pattern over to a chunk of procedural PHP code that tells you what to do there. And usually at the bottom of that PHP code, it returns something like a view, which is why we're kind of connecting these and routing. So let's talk about views and Blade a little bit. I actually wrote in my notes here, to be honest, I have no idea how to describe this to a five-year-old you can try, but if not, how you describe views to a procedural PHP programmer. So whatever it looks like. Can you talk about templating and Blade templating in particular? Caleb Porzio: Yeah. I guess if I were explaining this to pre PHP framework, Caleb. Caleb who is just learning PHP with WAMP or whatever at the time. Matt Stauffer: Right. Caleb Porzio: So when you encounter PHP, it's cool because it's it...So you could name file like about dot, like before you had about.html and it's your whole cool about page where you talk about yourself and you have a picture that's floated left, then you could change that with WAMP or something, some machine that understands PHP, we don't have to get into that, but you could change that to about.php and it would still work. It would work the exact same way, completely. But the magic is you could, let's say where you say, oh, at the bottom you have the copyright, like @copyright 2019, and then four years later is still 2019. Caleb Porzio: For that little 2019, you could basically break out of static, HTML, HTML that just exists and is hard coded into a file, into PHP with the syntax of Caleb Porzio: Was designing HTML sites, and then I thought, how does a username and password form work? I see the form tag, I see that on W3 schools, but what do you do with that? How do I do something smart? If I post this, I don't understand and that question is what led me to PHP and then Code Academy and then to Laravel and then to here. Matt Stauffer: Interesting, yeah. Caleb Porzio: So that then you get into PHP where you're actually doing smart things like handling a form request and going into a database and doing something deeper. So anyway, I guess all of this to say that at its core, PHP or at least the way it used to be primarily is a templating language. That's what it was for, is templating. But the needs have gotten so much bigger that the way we design our applications is not that way. We design them as if it's any other big boy programming language and then at the end you do all your work, you do all the calculations and computations and figure out what year it is. And then at the end you do the templating and then we call it the view. So it's kind of this shift of yeah, view is what PHP used to be for me, what all of it was. But now it's just where the HTML happens, you know? Matt Stauffer: Yeah. I like that. Because we definitely often think of the views is like the last little last ditch piece of it. Like there's so much code in so many files before you hit the view. And that's a really good point that even when my PHP applications got more complicated, there was 10 lines of PHP at the top of the thing that says include comma dot inc and connect my sequel parens or import header dot or template slash header dot inc or whatever. Yeah, totally. Caleb Porzio: Yeah. Matt Stauffer: But in the end, the primary file was still just the template and the template was bringing in the external code. And I mean, you could sort of think of it that way as well, but let's say instead of the template bringing in the external code, you now had the code itself bringing in the template, which is basically what a framework is, right? Caleb Porzio: Right, yes. Matt Stauffer: It's a whole bunch of code that Like it's, it's a whole bunch of code that at least for web views just brings in a template and throws data into it at some point. Caleb Porzio: And the one place, this is kind of funny, I think. I think not that long ago, maybe a month or two ago, I was just, I don't know what spurred this, but I just noticed, and everyone notices this, but every PHP file starts with that same less than, question mark, PHP. You don't have to end it, but it just starts with that. And you just do it like second nature, but other programming languages, you don't do that. You don't break out into the programming language, you are in the program language. Matt Stauffer: You are in it, yeah. Caleb Porzio: And so it's like this throwback that like we have one little nugget left that's hinting like, hey, I am a templating language. Matt Stauffer: The old days. Yeah, if you were to write these nowadays, yeah, there's probably some things you would do differently. One of them is probably not requiring that, yeah. Caleb Porzio: Not require it, exactly, that would be probably the first thing. And then I wonder, can you just write an HTML tag before that? I don't know. That would be fun. Matt Stauffer: Ah, that's an interesting question. I feel like you could in some, but a lot of the other ones, there's one of the things you'll hit just side note is that a lot of things, once the moment you write any HTML, it sends a header. And so you lose the ability to send headers. So if you had any HTML on any of your PHP tags, then your response would say, it would give you an error saying can't send headers or headers have already been sent. Caleb Porzio: Oh, I had no idea. Matt Stauffer: Yeah. Try it some time. Caleb Porzio: Okay. Matt Stauffer: Yeah, because the moment you echo any HTML to the browser, it assumes you're just getting generic headers. And so you can't customize your headers after that. Caleb Porzio: Wow. Good nugget. Matt Stauffer: Yeah. Caleb Porzio: Cool. Matt Stauffer: Yeah. Nugget. Yeah. And that's actually one of the reasons I believe why we don't end our PHP tags anymore so you don't have that accidental space at the end that gets sent as a character. I think, I think it's to protect us from that. Caleb Porzio: Cool. Matt Stauffer: Yeah. Got some old learning here. I think. The number of corrections I'm going to get on Twitter after this episode is going to be interesting. So, okay. So let's talk about Blade. So Blade is Laravel specific templating language, and of course, Laravel can work with other things like Twig and you could actually, I believe you could still just write straight up PHP templates as well. Caleb Porzio: Totally. Matt Stauffer: Yeah, if you just don't put dot.Blade@.PHP. Or actually I guess even in your Blade files. So what is unique about Blade or what makes you like Blade more than other templating languages you've worked with? Caleb Porzio: Yeah, so PHP itself is a templating language and sometimes I forget that, because there is like a for each colon. I remember I learned that after even learning Laravel, I think. Matt Stauffer: Oh yeah? Caleb Porzio: For each colon. I'd probably been doing open curly brace my whole life. Matt Stauffer: Yeah. Your life was changed. Caleb Porzio: Yes. Other templating languages, I mean, so other PHP templating languages, I don't really have experience with Twig. Matt Stauffer: Okay. Caleb Porzio: I guess, what is CodeIgniter? In CodeIgniter do you just use normal PHP for your templates? Matt Stauffer: I think you just use normal PHP. Caleb Porzio: I can't even remember. Matt Stauffer: It's been a long time, but I think so. Caleb Porzio: Yeah, okay. So well I guess that's maybe a good starting point in CodeIgniter you're in a controller. So just like in Laravel you have some route, it points to some controller method where you're returning the view. That's the end of it. And you're passing in data to the view and in CodeIgniter, you build up your view. So you remember this pattern, I'm sure you currently maintain an app with this pattern perhaps. Matt Stauffer: Not anymore. Caleb Porzio: Not anymore? Matt Stauffer: Not anymore, it's all Laravel now. Caleb Porzio: That's awesome. Matt Stauffer: Yes, but I do remember, I remember, I called it pasta view. I had a variable name pasta view in every method. Caleb Porzio: Okay, yeah. So basically you build up, in CodeIgniter I would build up a view. So I would first risk spit out a header and then the body, and then the footer, which is pretty good, it's logical. It's like procedural where Blade takes a different approach. Blade is like egg shells or something, instead of just stacking things on top of each other, you're spitting out a thing that then specifies what it's wrapped in and could be multiple layers of wrapping, which is very different. So in Blade you have the concept of layouts basically is what I'm getting at, which I like, because instead of, like in CodeIgniter you might have related things in the header and the footer, but they're in two separate files. Caleb Porzio: Where with Laravel your layout file is the whole glimpse. And then your content is one little bit, it's at yield content. So you get kind of the full picture of the right slices. And I liked that a lot coming to Laravel. That was a hurdle for me because it's a little bit more complex than just stacking HTML, but it makes so much more sense. And yeah. And then so Twig, I actually dug into Twig a little bit just to see if I could find any differences. And I couldn't really find much on layouts. I don't know if Twig just doesn't have the concept of layouts, but it's not like there was a page called layouts, you know? Matt Stauffer: Yeah, it does, but its inheritance is much less nuanced, but again, it's because of that I stopped using Twig, so I haven't used it in ages, but yeah, Twig doesn't do inheritance nearly the way that it does. And so I don't think you can do the type of layouts that you're talking about. It feels much more like the old way where you include one thing and then you include another thing and then you'll include a thing below it, rather than these ideas where you're leaving like little holes in it that say this hole is going to be filled later by something else that extends me, basically. Caleb Porzio: This speaks to all of Laravel for me, one of my, the things I love most about it, and I think we touched on with the routing is that Laravel is not all magic everywhere. Matt Stauffer: Yeah. Caleb Porzio: It's not a complete layer of frosting over hard wires. It's this beautiful mixture of the right levels of magic and the right levels of exposed brick. Matt Stauffer: Yeah. Caleb Porzio: And I think a perfect example of that is the routing. I love that it's not automatically assigning the code to my route. I love that I get that place for that. I think another good example is something in other templating languages when you are echoing something, so you have in Blade it's curly braces, two curly braces and then a variable. So if you're spitting out the current year, it would be curly brace, curly brace, date function, Y. And then it would spit out the year. In another templating language, you would likely have extra features like a pipe where you could add on a filter and maybe there would be magic things for uppercasing and lowercasing. And that's just more stuff you have to memorize. It's just more burden to bear. Matt Stauffer: Yeah, exactly. Caleb Porzio: And in a Blade you just use PHP. Like that's the recommendation, even though in the other ones you probably could, I think this is another area where I love how Blade, it doesn't have a feature or an API for everything. It puts you into PHP and it takes care of the things that are normally a little annoying. Matt Stauffer: Yeah, yeah. Which I mean, and I think that's a great point because actually I believe in Twig, you can't use normal PHP. And so you'd find yourself in a situation where let's say you wanted to do an array filter on something in Twig, well, array filter doesn't exist in Twig. You have to go see if somebody has written or you have to go write yourself an array filter Twig extension, which I've done before. And I don't know if I did it with that, but if we had to do things and it's actually like you have to develop a whole package to use this one feature in Twig. And not to say Twig's terrible or anything like that, but with Blade, at any point you can just drop down to PHP. Caleb Porzio: Yeah. Matt Stauffer: And Blade makes certain things a lot easier like full reach and if an inheritance and all kind of stuff, which is great and we're very grateful for, but in the end, you're just writing PHP templates that have some decorative language in them, rather than writing a brand new thing that you have to not only memorize everything, which isn't the whole thing, but also you can't do anything that's not in their defined spec. So yeah, I love that. That's a really great point. Caleb Porzio: Yeah. One thing I think worth mentioning for newcomers or latecomers or whatever, that the curly brace, the double curly brace, echoing something in Blade. What's the difference between just doing open up PHP and echo, because it is functionally the same thing, but in inside when you do that, you're also escaping whatever you are echoing out. So in other words, if you have a database field of a user's profile, their about section, and you make it a text area on the page, and let's say, I don't know, however this happens, they write literally HTML inside of that that has a script tag with some bad script injection stuff. And you echo it out, you echo out the user's about on a page publicly, you would expose the world to this JavaScript attack. Caleb Porzio: Where Blade, when you use those double curly braces, you're automatically protected from harm basically, it escapes those out. So you'll actually see those HTML tags literally shown instead of processed by browser. And I think that's an important note for people that you're just taking care of in a way that is kind of behind the scenes. Matt Stauffer: I love that because one of the things we've long said is that Laravel takes care of you in certain ways like that. Like it protects you from sequel query injection because it by default escapes, all that, these things. But I think there's a lot of other ways that it helps you learn that I have not realized. And until the last couple of years, which is just to give one example, a lot of people have told me when I ask them, where did you learn design patterns? They said, I had to learn them to work with Laravel because the design patterns are embedded in Laravel. And so in order to understand how to work with Laravel, I had to learn this design pattern. And I'm like, that's a really interesting idea. So Laravel is actually helping us do better in a lot of different ways that we don't always necessarily know. Caleb Porzio: For sure. Matt Stauffer: But you're right, yeah, you don't have to know that you're being protected in order to be protected. You don't even need to know that you need to be protected in order to be protected, you just are. Caleb Porzio: Yep. Yeah. It's invisible until the day where you need to actually echo out something unsafe for a purpose. Matt Stauffer: And then you can go learn what you're doing. Wow, I was protected this whole time. That was great. Caleb Porzio: Yeah. Matt Stauffer: Yeah. Caleb Porzio: Yeah, totally. Matt Stauffer: That's cool. So, okay. So the simplest use case for routing is routing, just taking a request and spitting out results. The simplest use case for Blade is views, but there's other aspects of working with routing, there's other aspects of working with views that are a little bit more common, but maybe a little bit harder to kind of either understand at the beginning or describe. And some examples there are like, for example, route groups is one thing that's a little bit more complex. I know that views has stacks and there's also sections and stuff like that in yield. Could you talk about a few of the most common patterns and tools between routing and Blade that you use on a regular basis or you think people do that'd be good for everybody to at least get familiar with? Caleb Porzio: Sure. Is there a section of this episode where we talk about common gotchas or is this this section? Matt Stauffer: Yeah, that's the next section. Caleb Porzio: Okay. I just got to make sure that I get there otherwise I would stuff my gotchas in here. Matt Stauffer: Totally. Yeah. That's next. Caleb Porzio: Yeah, I guess common like next level mechanisms for routing, grouping is perfect. So let's say you have a whole chunk of, okay, your landing page on the site is a public facing site or it's a public facing route that you want to spit that stuff out to the public. Your login page is a public thing, but then everything inside of your application, the admin panel, that's all protected under authorization, user authentication, a user has to be logged in to see that stuff. Caleb Porzio: And I think that this is great, but the way to do it in Laravel basically is to take those routes and put them inside a route group. So you might have a route group for all of the public routes and then a route group for all of the non-public routes. And when you declare a group, so actually the syntax, like route colon, colon group, and then you can pass in a callback or just a function of PHP, closure, whatever, where you then declare all your routes. So you'd copy and paste all your routes and stick them in that function. But when you're declaring the group, you can assign it things, you can assign it middleware like auth or guest, if you want to kick guests back from visiting it. Matt Stauffer: Yeah. Caleb Porzio: Yeah, I mean, it's great for a place for middleware. It's great for prefixing, you can prefix a whole group. If everything in an admin panel should be slash admin, you can pass like route colon, colon group, and then prefix slash admin. You can also prefix route names, which segue, we should talk about route names. That's a good one. Matt Stauffer: Totally should. Yeah. Caleb Porzio: Yeah. Matt Stauffer: Huge, huge boom to start using that. Caleb Porzio: Yes. That's a good tip. Like I remember early on sort of seeing the light and never looking back in every other framework or anything I've used when you're dealing with routes all the time, you have your homepage, which has a log out button and maybe that button posts to an end point slash log out. So you hard code, you literally write in slash log out, then way down the road you need to rename it for whatever reason to off slash log out. And now you have to do a global find and replace, which is easy in that case, but in other cases, it's not always easy. There's maybe wildcard stuff. Maybe you used PHP to build up that route and then it becomes harder and more brittle, more fragile. It just becomes a chore basically, if not a liability. So route names are like variables. It's a map, basically, route names are variables for maps. Matt Stauffer: Yeah, another map, yeah. Caleb Porzio: Yeah. So when I'm defining a route, let's say I have an admin route, route colon, colon get admin, and then I'd put in a controller method or something. And then at the end of that, instead of just putting the semi-colon, I could do arrow name and specify a name like maybe it's just admin, but typically they're more nested. It might be like auth dot log out, or admin dot show dot something. Matt Stauffer: Yeah. Yeah. Caleb Porzio: So now you have basically it turns what was just hard coded strings everywhere into a function that you can interact with. So now when you're echoing out that log out, instead of just hard coding slash logout, you would route as a function, route function, and then pass in the string log out or off dot log out, and then it would echo out itself. Matt Stauffer: Yeah. Caleb Porzio: So that's a good one, I think that's a good mechanism. Matt Stauffer: And you made that transition when you were talking about groups and that's a great point. Like for example, if all of your admin routes in a group, you can both prefix the URL with admin, but you can also prefix the name with admin. So you can assume that all the names of those routes are going to be admin dot something. You can also do it once in the group, rather than having to duplicate it every single time for every single route in that group. Caleb Porzio: Super useful. Matt Stauffer: That's a great point. Are there any Blade things that you want to talk about that are, that are really valuable more than just basic Blade? Caleb Porzio: Right, I mean layouts are really valuable. Matt Stauffer: Yeah. Caleb Porzio: And maybe one of the, this is something I used to be scared of. I think that layouts in Blade is a little bit of a next level concept. I think for new people, if new people are like me when I was new, it's one of those things you struggle through to get set up in your app, meaning you have your base layout that has your loads, whatever bootstrapper tailwind, CSS, your head tag, whatever. And then maybe a section of your site is we'll use the admin panel. There's specifics about the way the admin panel, the header, the footer, stuff like that, the sidebar. So you have this kind of middle layout and then you have your end view, which are all the different views inside of admin. That setup is something that every time I needed it, I would struggle through, read the docs, go through everything, look it up, look at example apps, get it done, and then never think about it again and then dread it the next app that I was building. Do you identify with that? Do you ever remember feeling that way? Matt Stauffer: Yeah, a hundred percent. Yeah. And usually for me it was because I didn't understand what needed to go and what, and also which terms to use for each section and extend and yield and all that kind of stuff. Caleb Porzio: Yes, exactly Matt Stauffer: Yeah, yeah. Caleb Porzio: And I don't have the cure. I think you learn over time. But I do have one cure. Matt Stauffer: Yeah. Caleb Porzio: One specific tip that basically, because I would get very overwhelmed with, okay, if you just do section and yield, section and then end section and then yield those sections, if you just do those, it will not work. It will work for just two layers. But if you have that middle layer like I was describing we have the base layout and then your app layout and then the actual view, the actual view will overwrite that middle layer. It'll just get rid of it because that's the way that Blade's sections work. When you're in that nested egg shell thing, the middle shell takes precedence over all the extra shells when you're dealing with the same section. Anyway, the cure is that in all those middle sections, instead of at end section, you do at overwrite, that is the cure. It is actually not documented. Matt Stauffer: Is it not at all? Caleb Porzio: It's actually hard to find this answer now. You should go there and check me if you just command F at overwrite. I'd be kind of willing to bet you don't find it. We're doing it live. Matt Stauffer: We're doing it live. Except my Internet's going slow. Hold on. Oh, look at this, warning, you're browsing documentation for an old version Laravel. I think I may have been involved in that decision to put that little note there. I just forgot it. Caleb Porzio: Oh, that's a great note, I love that. Matt Stauffer: Yeah. So the one I know is that there's add section and end section versus at section and at show. I kind of thought that add section and overwrite didn't want to do it because overwrite actually overrode it, whereas at show allowed it to be extended or something like that. Caleb Porzio: Isn't it weird? You would think overwrite would be what I described as the default behavior. But override is like stack. I don't know why it's called overwrite. And I don't know why it's not documented. Maybe I found it source diving or something, maybe show is the thing to do. But show end section and then at show to me is weird, the language is weird. Matt Stauffer: Yeah. Caleb Porzio: It's a thing to get tripped up on. So I'll at least say, for me, in every app I've ever built, at overwrite is the cure to these problems. I'll just put that out there, but people, look at the docs, maybe don't use it, maybe use at show. Matt Stauffer: Let's do a little digging after the thing and maybe if either of us come up with the perfect thing, we'll tweet it and I'll put it in the show notes. But there's definitely, when you start with a section, you can either end it in end section, show, or overwrite, which is not documented. Matt Stauffer: So I do actually want to step out for just one second. If you have never worked with Blade, a lot of our conversation here about templates has probably been a little bit confusing. So really quickly, let's just talk about templates. So let's imagine the most common Laravel app structure, which is not three layers like Caleb was just talking about, but two layers. You've got a file that is your primary template called usually layout slash app Blade dot PHP, that has everything that all of your pages are going to have. So like he was saying, it's going to be opening HTML tags and your head tags and your footer tags, stuff like that. And then where that content is, remember just like we were talking about with the PGX there's this content section in the middle that is really what's different from page to page. Matt Stauffer: Instead of putting the content there, you'd put the words at yield and that's it, at sign yield. And then all your actual content pages, aren't going to be full HTML page. They're going to be basically two things. The first line we'll say at extends and then in that you pass in the name of the file that you were just built as your layout style app. You don't have to put Blade dot PHP and that dot gets replaced with a slash. So if you say, add extends layouts dot app, what that means is go look for a file in layouts slash app dot Blade dot PHP and considerate it the template. Matt Stauffer: And then from there you define a section. So you do that, two new lines, and then at section and then you put the name of the section. So if we named it content before you say, add section content, and then you type whatever you want to be in that middle body and then you do whichever the appropriate one is at show or at end section or whatever. And then that gets passed into the pair of template, they're mushed together, and then that's the outfit. Matt Stauffer: So when Caleb was talking about templating, that's really one of the most powerful things about Blade is the ability to do that thing where individual templates yield or open up certain kind of sections to have other things put content in them. And then later ones can extend that parent one and to find those sections in there saying, hey, give me everything that parent one has and when it asks for this little section, here's what you should put there. Yeah, so is that a pretty good description, Caleb? Caleb Porzio: Yeah, yeah, really good knowledge to fill in, yep. Matt Stauffer: So can you, I just want to poke on one of them because I think it's valuable and I don't think a lot of people know about it. Can you tell me about stacks a little bit? Caleb Porzio: Yes. So I'm going to start at a place where maybe most people won't grab on, but I think it's a fun way of thinking about it. I think a better way to think of stacks is the portals concept in view or react. So if you're familiar with view, consider this problem. You are building an app, it's a view application, view as a JavaScript framework, whatever. And it's a, oh, I don't know, whatever. It's a FUBAR app, who cares. In the middle there's some component called body or modal or something where you have a form, whatever, I don't know. From that component, you have something that you want to show in the footer of the page. Like there's maybe a button to hit next or to hit hide or something like that. You basically, you want a portal, like the concept of, I'm trying to think of a good example of portal, portal the game, Rick and Morty's portals? Matt Stauffer: Yeah. Caleb Porzio: Whatever. Everybody knows portals. Matt Stauffer: Yeah, they know what portals are, it's glowing, takes you other places. Caleb Porzio: Yes. So in view, there is a concept of portals. I think it's native in view three now, I don't know. I think it's going to come out of the box. It used to be a plugin. Matt Stauffer: Oh, cool. Caleb Porzio: Basically where from any component, you could shove stuff into a portal and then you could fetch stuff out of the portal from other places in your app. So in that footer, you could designate a portal target, which is saying like, here's where I want, and you would name it with another map. So maybe it's portal target footer. Then from any component you could say, shove this block of HTML through the footer portal and it'll show up there, which is great. Caleb Porzio: And then you can set it for certain behavioral, let's say there's three different components that are shoving HTML into these portals and they're all coming out at this. By default, it would overwrite each other until the last one wins, but you can add the ability or specify the ability to append so that each new one is appended to the bottom. So I think that is a good mental model for stacks in Blade. Matt Stauffer: Yeah. Caleb Porzio: It took me awhile. The reason I came to this is I started writing portals in Blade. And then I realized I had re wrote stacks. Matt Stauffer: They already exist. Caleb Porzio: And I was like wait a minute. This is stacks. So the concept of a stack. Similar to a portal, a stack is something you can push to, you push from any Blade component in your entire app. And it will pop out wherever you specify a stack. So at stack footer, whatever, you could put that at the footer of your main layout and then from any Blade file anywhere, you can say at push footer, specify, and then just throw in HTML and it will show up there and it will automatically, it's called stack, you can guess that it would append, but it's stacks stuff on top of each other. And we can talk about common uses in a second, but how's that for a definition? Matt Stauffer: Yeah. Oh, that's great. And I think that the easiest way to understand is the most common use case, which is pushing JavaScript scripts into your footer that only one template needs or something like that. I think that's a perfect description. And if you're not familiar with portals, I think if you can just imagine that any of your individual template sections could, regardless of where they are on the Harrington's tree or at show or at end section or whatever, they could just say, hey, I don't care what's in there right now, just throw this script tag into there and just call it a day. And that's all you got to do. Caleb Porzio: Yes. So that is a common pattern where there's certain, every app that I have, I have a base or layout slash app dot Blade dot PHP or based off Blade in PHP. And then right before the end of the body, I have a stack called scripts. So at stack scripts, and then in the head tag, right before the end of the head tag I have at stack, usually I call it styles. That's just my own, styles and scripts. Matt Stauffer: Styles, me too. Caleb Porzio: And then anywhere else in my Blade file, so if I have a page called show user, whatever, and I return a Blade view called user dot show. Inside of it, you have the at extends. Then you have the at section for your whole content, but then you include some like a JavaScript image cropping library, or whatever. You include some bit on there that needs JavaScript, but you don't want to necessarily include that JavaScript on every page. So just on that page, after all of the other Blade stuff, after the at section, whatever, I'll have an app push scripts, and then I'll paste in the link to the CDN or the JavaScript file on my machine. Caleb Porzio: That's a common use case for me because it's nice that I don't know, it's a really nice pattern if you don't want those scripts scattered in the middle of your file. Or even if it's the JavaScript that you write yourself, like in a script tag, you want that stuff at the end of the page so you're not blocking the rendering of your site. So script stuff goes in at push scripts and then occasionally I pull on at push styles. Matt Stauffer: Yeah, same here. Caleb Porzio: Stacks is a good one. Matt Stauffer: 100%. Caleb Porzio: I have a friend, he's heavy into stacks, it's like the only Blade abstraction he uses. He's a wild man. I think he uses it for layouting, for everything. He just loves it. Matt Stauffer: I don't know if I could do that, but I'm curious to see what it looks like in the end. Caleb Porzio: I should say that I was talking to Taylor about some layout stuff with Livewire and we were working on the new components, which we need to talk about. And we're just brainstorming on components and I'm talking about some hiccup with layouts and he goes, "Actually man," he's like, "I just use components for everything." And I'm like, what are you talking about? And I just saw it. So then I was like- Caleb Porzio: I'm like, "What are you talking about?" And I just saw it. So then I was like, "I need to just do this. Give me a second." So I go and I create a new app and just instead of the whole layout confusion, whatever, you have a component called "layout" with slots. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: And I'll stop with the words here, but I'll say that I'm pretty sure Taylor doesn't even use layouts anymore. Matt Stauffer: Interesting. Caleb Porzio: I think he uses Components for everything as the only abstract. Matt Stauffer: Okay. I'm going to have to pick his brain about it later. Caleb Porzio: Yes. Matt Stauffer: But you know what, we are about to get into common challenges and gotchas. So before we do, why don't we touch on Components? Caleb Porzio: Yeah. Matt Stauffer: Components is brand new as of two months ago, and I know that you were a part of it being introduced, and Components in Blade, actually parallel Components in Livewire super well. Caleb Porzio: Yes. Matt Stauffer: So can you just tell us? That's another reason why you're the perfect person to be on this podcast. So can you tell us a little bit about Components? Caleb Porzio: Yes. So we'll start with includes, the concept of includes in a Blade file. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: @Include is a Blade directive. Directive is the word for things that start with @ in Blade. Matt Stauffer: Yep. Caleb Porzio: So @include and then you specify a file, a Blade file. Matt Stauffer: Right. Caleb Porzio: And it'll basically just shove it in there, so super simple concept. So Components, a while ago, I don't know when they were introduced. They've been introduced and they expand on the concept of an include. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: So they're kind of like an include except it's worth noting that their scoping is different. I don't know if we want to get into that, but I'm going to skip it for now. But it is a gotcha. Maybe when we talk gotchas, we'll talk scoping issues. So instead of @include, you can do @component. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: And it behaves just like an include on the surface. Matt Stauffer: Yeah. Caleb Porzio: But you could also add an end@end component after that and shove HTML inside of that, which is a slot. If you're familiar with Vue.js. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: That's the concept of slots. So this was, Taylor's first attempt at bringing some more advanced templating that we saw from the Vue world and JavaScript world, bringing it into the backend templating world. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: Yeah. And there were some cool things there, so that would be the starting point. But I'll say that wasn't enough for me, having tasted Vue. Matt Stauffer: Right. Caleb Porzio: Having my biggest complaint with Blade is that it feels antiquated and the Components in Vue are such a better abstraction. Matt Stauffer: Yeah. Caleb Porzio: In terms of their slots, there's name slots, there's attribute forwarding. We can get into that later. They look better, they look like tags so there's syntax highlighted where Blade Components are @component and then a big long list and so whatever. So I wrote this manifesto of basically Blade would be amazing if the Components were just like Vue. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: So I wrote out like the spec of they need to have this, this, this, this, and this. And because I had written Livewire, which is built on this concept of Components. Matt Stauffer: Yeah. Caleb Porzio: I had already had sort of an arsenal of like, here's exactly how it could work without the live part. Just the component part. Matt Stauffer: Yeah. Caleb Porzio: Because people were using Livewire Components without the Livewire. Matt Stauffer: With out any other activity. Caleb Porzio: Just as a better component of extraction. Matt Stauffer: Just because of good organization. Yeah, totally. Caleb Porzio: So anyway, Components got a huge upgrade in the latest version of Laravel. Matt Stauffer: Yeah. Caleb Porzio: Laravel 7 and I adore them. I think they've redeemed blade. Matt Stauffer: Yeah. Caleb Porzio: I think people are all about them and the craze will only continue. Matt Stauffer: Okay. Caleb Porzio: I think they're bringing people back to blade. They're so sexy. Matt Stauffer: Wow. Caleb Porzio: I do. Matt Stauffer: All right. Caleb Porzio: I do you believe that. Matt Stauffer: That's awesome. Caleb Porzio: Okay. Matt Stauffer: I mean, I love them but it's interesting. I've never imagined the idea of using them for a full layout, but now that I'm thinking about I'm like, "Yeah, totally makes sense." So now my next challenge to myself will be to be using only Components, no inheritance and see how I feel about it. Caleb Porzio: Yeah. Matt Stauffer: It's kind of a composition over inheritance type thing. Right? Programming already tells me I'm supposed to do that. So it's obviously better. Caleb Porzio: Yep. It's perfect. Matt Stauffer: So it's obviously better. Caleb Porzio: Yeah, the concept of slots is closures and programming. It's great. Matt Stauffer: Mm-hmm (affirmative). I like that. Okay. Let's get onto common challenges and gotchas. So first we're going to jump back to routing for a little bit. What do you think gets people tripped up the most as they're working in either learning routing in Laravel or just in general? Why do you think people get stuck on the most was routing? Caleb Porzio: Fortunately, it's really simple. So I think it's like, I don't remember struggling with it a lot. I don't think it's something that trips people have too much. Because it's fairly straightforward, I think. But I do have a couple specific gotchas that I've run into. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: So how really honestly, the big one that I think is a little deeper is, okay, when routes, yes. When you have two competing routes in the same file. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: So if you have... So here's a thought experiment. You have route get Matt Stauffer and then echo, Hey Matt. And then you have route, get Matt Stauffer right after that echo, Hey Caleb. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: And then you go in your browser to /Matt Stauffer. What shows up? What do you think or what do you know shows up? Matt Stauffer: Hey, Caleb. Right? Caleb Porzio: Right. And that would make sense because something declared after another thing overwrites that thing. Matt Stauffer: Yeah. Caleb Porzio: That's what you would think. And that is the way it works. Matt Stauffer: Yeah. Caleb Porzio: Now let's say that I declared- Matt Stauffer: I was waiting for you to tell me I was wrong and I'm like, "I don't know about this." Caleb Porzio: No, I'm saving that. Matt Stauffer: You're saving the time where I'm wrong for a second. Caleb Porzio: Yes. And you might not be wrong you likely know this. Matt Stauffer: We'll see. Caleb Porzio: But this is something that is always confusing to me. And I had before this call, I just decided to check it out, to get an answer. Matt Stauffer: Oh, yeah. Caleb Porzio: To gift to the listener here is the answer. Matt Stauffer: I love it. Caleb Porzio: So wildcard routes in Laravel there a way to, you could say route:: you're going to tell me what the syntax because I write them so infrequently route::get/ you could do /star. Is that right? Or is it curly brackets and then star? Matt Stauffer: I think it would be curly brackets and then I don't even think it has to be star. Oh yeah. You mean the global wildcard not just for a section? Caleb Porzio: Well, let's just say it's just a section. Matt Stauffer: Okay. Caleb Porzio: Forget about the global stuff, forget about the asterisk. Matt Stauffer: So let's do /posts/bracesid. Right? Caleb Porzio: I'd like to stick with the original Matt Stauffer. Matt Stauffer: Okay, got it. Caleb Porzio: Because we have everybody in that line space. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: So we had route get Matt Stauffer and then route get Matt Stauffer. Matt Stauffer: Yep. Caleb Porzio: Now the above route get Matt Stauffer becomes route get curly brace name whatever. Matt Stauffer: Right. Caleb Porzio: End curly brace. Matt Stauffer: Yeah. Caleb Porzio: So in Laravel this is a wildcard route. And anything that matches it, like you were getting at, if it's /post/curly brace ID, everything with slash posts will hit that. And then whatever is the ID will get passed to the route. Matt Stauffer: Right. Caleb Porzio: So anyway, you would think that you would declare a wildcard first. And then if I declared route, get Matt Stauffer after that would be the thing that would take precedence, you would think that. Matt Stauffer: Yep. Caleb Porzio: You declare the catchall and then you declare the specific instances. Well, if you go to Matt Stauffer in the browser, you would get Matt Stauffer. So this is a common gotcha I think because it's reversed, it's un-intuitive. Matt Stauffer: Yeah. Good thinking. Caleb Porzio: You have to declare the specific routes above the wildcard routes for them to properly work. Matt Stauffer: Yep. And it's because the fact that the wildcard routes once defined have captured that thing and they don't even get to make it passed to the other one. Caleb Porzio: Yes. Matt Stauffer: That's interesting. Caleb Porzio: Yeah. Matt Stauffer: That's a good point. Caleb Porzio: It's actually, there's a bug in Livewire that I just dealt with in testing that somebody just PRd so that brought Livewire registers a route. I have to then bust it out so that it registers at first because they have a wildcard route in their app. Matt Stauffer: Oh, interesting. Caleb Porzio: So I have to make Livewire more flexible so that it doesn't break their app. Matt Stauffer: Yeah. Caleb Porzio: But this problem that some people come across. Matt Stauffer: I ran into that problem. Okay. Yeah. I ran into that problem when I was doing translations on on-ramp because I had to do wildcard where the first segment of your entire app is going to be the language that you're working in. Caleb Porzio: Okay. Matt Stauffer: Because there's different structures. Caleb Porzio: Sure, right. Matt Stauffer: And so Nova stops working and the Auth stops working. Caleb Porzio: Yeah. Matt Stauffer: And all these different things because they're all expecting to be at the root. And so I had to bypass those things and weird or add whatever, all these different things to just allow the fact that the first route is going to be this except in these certain circumstances. And sometimes I couldn't do that because, the way you're thinking, because those routes were bound in a service provider. Caleb Porzio: Yes. Matt Stauffer: And that service of was loaded later. So, and then I had to do these weird... It's a language, unless it's one of these and then it's actually a pass or whatever. So yeah. There's definitely some dances to be done there. Caleb Porzio: Yep. For sure. Yes. Yeah. Matt Stauffer: Yeah. I would say that in general root level wildcard is going to bite you at some point. Caleb Porzio: Yes. Matt Stauffer: And that's why the healthier one is to do only do those in /posts/ whatever. Because, okay, that's going to make more sense. You still, "Well, what happens if I want /post/create or whatever." Caleb Porzio: Yeah. Matt Stauffer: Okay. You still have to think about those things. Caleb Porzio: Yes. Matt Stauffer: But there's less of them in that context. Caleb Porzio: Right. Matt Stauffer: Okay. So, Oh, sorry. Do you have more for routing? Caleb Porzio: I don't think so. Matt Stauffer: Yeah. I was going to say, I think that the only two are one is wildcards and two is if you're using any of the magical matching they were talking about before, where you're using resources, controllers and stuff like that. Caleb Porzio: Sure, okay. Matt Stauffer: Sometimes it can be hard to know where the match is coming from. Caleb Porzio: Gotcha. Matt Stauffer: Which is why I think explicit really valuable with routing. For sure. Caleb Porzio: Yes. The more explicit the better. Matt Stauffer: Yeah. Okay. So let's talk about Blade. What are common gotchas? What gets people most tripped up when they're using blade? Caleb Porzio: Yeah. I mean the @override, I think is a common one. Here's another one. So when you @include a section of HTML, so let's say you're returning a file called "show user" you're returning a Blade view called show user and it shows the user's profile, the avatar stuff like that. And there's a bunch of redundancies on the page. Maybe every row in the user's info is you repeat all this HTML. So you might break out an include. Matt Stauffer: Yeah. Caleb Porzio: And an include is an abstraction. So it's a variable of HTML. So you could break out some section and include whatever. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: The HTML, the Blade in that include has access to all of... it has access to the parent's scope. Matt Stauffer: Yep. Caleb Porzio: It has access to all the variables that your Blade view has access to. Matt Stauffer: Yep. Caleb Porzio: So if you pass a variable into your view from a controller, your includes have access to it. No problem. Matt Stauffer: Yep. Caleb Porzio: When you use a Blade Component, they're walled off. Matt Stauffer: Yeah. Caleb Porzio: So the scope does not bleed into the component and you have to explicitly pass those things in as parameters into the component. So you do a lot of prop drilling, basically prop forwarding. Matt Stauffer: Yeah. Caleb Porzio: I prefer it that way. And in includes you can actually pass variables into includes the same way you do a component. Matt Stauffer: Yep. Caleb Porzio: Which is nice. But, yeah. I think that's just a good thing to know, Blade scoping, I guess. Matt Stauffer: Yeah. Caleb Porzio: That the components aren't scoped and includes are, I don't know, just a nugget. Matt Stauffer: I also think that @each, which is basically a convenience layer around... I think that this is the right one. Around for each and include at the same time. Caleb Porzio: Oh, sure. Matt Stauffer: Where you basically say @each and the first things, the list of things you're fore reaching the second one's the template. It also doesn't do, it doesn't pass the variables out of it. Caleb Porzio: Oh, interesting. Good to know. Matt Stauffer: It's either that or some other convenience level like that. Caleb Porzio: Yeah. Matt Stauffer: But I think it's @each that doesn't have it. Caleb Porzio: I'd stay away from that syntax. Matt Stauffer: Yeah. I love it because I have to do @each includes all the time, although I'll probably end up moving to Components, but I do think, I remember one of the things that you run into is in the docs even say, "You can, @each and you get past the item of the array that you're iterating over." Or the whatever, the iterable, but you don't have the ability to get all the other things. And the docs literally say, "And if you need them just go to the classic @foreach@include syntax. Caleb Porzio: Gotcha. Yeah. Good to know. Matt Stauffer: Yeah. Caleb Porzio: Yeah. Matt Stauffer: Any other things that you think that gets people tripped up about Blade a lot? Caleb Porzio: Yeah. I think this is a concept that I've recently, since building Livewire I got real clarity on and it's simple enough that I wish I had clarity way earlier. Matt Stauffer: Yeah. Caleb Porzio: And that is compiling. Blade compiling. Matt Stauffer: Yeah, let's talk about it. Caleb Porzio: Where that happens, when that happens, what is it? It's a concept that first I'll start where you might experience where you might touch this problem or this feature, I guess. So you are developing your Laravel app and you have an error in your Blade file. So you have you show user.play WPHP and let's say you literally throw an exception, who knows whatever, have some bad syntax. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: The error message that you get will not... I actually don't know. The error handlers in Laravel ebb and flow in terms of how well they handle this sort of thing. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: So I don't know what it's like right now with Flair, but whatever, when you hit this error, you will likely see a reference. You will be expecting to see your Blade file. Matt Stauffer: Yep. Caleb Porzio: You'll be expecting to see the reference in the air to say /user/show.blade.WHP. You will not, you will see some obscure reference to a file called blah, blah, blah, blah, blah, blah, blah, .blade.PHP or .PHP. Matt Stauffer: .PHP, yeah. Caleb Porzio: Yeah. Buried somewhere in some hidden, seemingly hidden, directory that will sort of look like your file. Matt Stauffer: Yeah. Caleb Porzio: But there'll be no Blade. And you might catch that or not. Matt Stauffer: Yep. Lost PHP tags, yeah. Caleb Porzio: It's just PHP. Yes. So, that is because all of the Blade that you write, isn't what actually gets run by PHP. There's a compilation step that goes through and uses reg X searches for syntax that like, "Oh, @foreach? Well, we're going to replace that with actual PHP for each." So there's an entire compilation step that happens. Yeah. Before the code is actually run. And I think that is... It causes, there's a disconnect there, I think for people. Matt Stauffer: Yeah. Caleb Porzio: Especially with errors in their Blade. Matt Stauffer: Yeah. Caleb Porzio: So, yeah. So I'll start there. And I have one extra tiny nugget with that. Matt Stauffer: There's an interesting note on that one as well, which is that you can cache those views so that they're all generated once and then they don't have to be generated on the fly. Caleb Porzio: Yes. Matt Stauffer: And so you should consider doing that as a part of your deploy stuff, but don't do it locally or otherwise you're going to have to re-cache, regenerate the views every single time. Caleb Porzio: Right. So, yeah. So this is a good point. I thought as a not knowing how Blade caching works just from an outside in there's Artisan view cache, whatever. Is it Artisan view cache for Blade caching? Matt Stauffer: I think so. Caleb Porzio: Yeah, okay. Matt Stauffer: I think so. Caleb Porzio: So Artisan, yes, definitely. Matt Stauffer: Okay, cool. Caleb Porzio: Artisan view cache and so I thought, "Oh cool. Everybody's talking about this optimize, do it on the servers. Great, makes sense, cache all the views." I thought that it was some extra caching thing, some extra thing that I'm adding some layer of caching. And if I have a problem, I'll just get rid of it and go back to slow PHP. Matt Stauffer: Uh-huh (affirmative). Yeah. Caleb Porzio: I will say that that is not the case. Every view that ever gets run is cached. Matt Stauffer: Yeah. Caleb Porzio: So when you run view cash, it's just preemptively doing it. Matt Stauffer: Yeah. Caleb Porzio: But when Laravel hits a view that it hasn't cached, it will cache it and then it'll hold that cache. Matt Stauffer: Yep. Caleb Porzio: And it will expire that cache when it recognizes a difference between the file modified time on your cached view and on your Blade file. Matt Stauffer: Yep. Caleb Porzio: That's how it works. There's literally a bit of code in Laravel's code base, file M time greater than file M time then redo the cache. Matt Stauffer: Yep. Caleb Porzio: So it helped me to understand that, forget about Artisan view cache, Laravel is always caching views. Matt Stauffer: Yep. Caleb Porzio: Artisan view cache is just pre-cache them all. Matt Stauffer: It's just a micro optimization so that no individual user has to be the first person to hit that cache right now. Caleb Porzio: Yeah, so I don't even do it. Matt Stauffer: Yeah. I mean, it's certainly, it's- Caleb Porzio: Maybe I should. It seems minuscule to me. Matt Stauffer: It's exactly what you said. It's minuscule. Because I'm in the practice of running all the caches when I deploy, I just throw that one in there, but you're 100% right. So, and interestingly, I do think that one of the things that's beneficial with the view cache, you can also do view clear, I believe. Caleb Porzio: Yes. Matt Stauffer: That's the more helpful one. Caleb Porzio: Exactly. Matt Stauffer: Because every once in a while, because of get pulling or something like that, you're going to get an issue where it's very infrequent where Laravels unable to notice that the view should have been recompiled. And so if you're like, "I am a 100% changing the source files, it's got to be Laravel's fault." First of all, most of the time it's actually, you're changing the wrong source file. But every once in a while, Laravel caches them wrong and then you do Artisan view clear, I think is what it is. And that actually wipes all those cached files. Caleb Porzio: Here's the scenario where this will predictably occur and is a good known for everybody listening. If you are ever creating your own custom Blade directives or aliasing Blade Components or anything like that, if you're ever doing that, those changes. So consider this example, you have the user show thing, you can create custom blade directives, we haven't even touched on it. It's fun, we're not going to get into it, but I've already explained directive. So you could create @MattStauffer and your use, whatever. Matt Stauffer: Yeah. Caleb Porzio: And it's going to echo out Matt Stauffer. So in your service provider, you would say Blade::directive Matt Stauffer, and then pass in a closure where you echo out Matt Staffaur. And so then in that view, you have @MattStauffer, you save it, you hit refresh on your browser, you see it on the page. You go, "This is great. I have my new custom directive." Matt Stauffer: Yeah. Caleb Porzio: And you go, "Wait a minute. It should say Caleb Porzio." So then in your service provider, you go and you change the echo from Matt Stauffer to echo Caleb Porzio. Then you refresh and it doesn't change in your browser because if you think about it, no file modified time has changed. Matt Stauffer: Yep. Caleb Porzio: You've changed that directive at runtime. So you have to Artisan view clear. So that's why you'll see a lot of packages who provide changes to directives when they upgrade, run Artisan view clear. If you use Nova, you have to Artisan view clear because they, whatever. Matt Stauffer: Yeah. Caleb Porzio: So anyway, that is note I have to be aware of a lot. Matt Stauffer: There's another very common one, which is that, that I've run into, which is that if you are bringing in a package that offers a directive and you put the directive call in your template, hit save before it finishes composer requiring the template. Caleb Porzio: Oh, yeah. Matt Stauffer: So for example, if you're using Ziggy, this happens all the time. Caleb Porzio: Oh. Matt Stauffer: Someone types @Ziggy or @routes or whatever it is into their template, hits save, and then goes and does composer require technical/Ziggy and then they refresh the page. And it's just still says @Ziggy. Caleb Porzio: Right. Matt Stauffer: Because that template does not have a new modified time. So you can either go just literally hit enter and hit save so it gets new modified time or run PHPRs and view clear and all of a sudden now register it. And that was one of the biggest things we ran into customer support issues with on the...or whatever you want to call them, is just, "Why is it not working?" Caleb Porzio: Yeah. Matt Stauffer: And I remember hitting it once and I'm like, "I'm losing my mind." Caleb Porzio: Right. Matt Stauffer: And it was exactly that there was lots of files that were modified when I require that package. But the views to render this view were not any different afterwards. Caleb Porzio: Yep. I get that with @Livewire, same thing. People showing me just a page that says @Livewire. Matt Stauffer: Okay. Cool. Caleb Porzio: And it's always the same thing, yeah. Matt Stauffer: It's the exact same thing, man. Caleb Porzio: Yep. Matt Stauffer: Yep. And the other instance for that is if you...that shouldn't happen. Oh, if you pull the updated, so if somebody adds Ziggy or Livewire or whatever in a pull request, and then you pull down the updated code and you view it and you see @Ziggy and then you go, "Oh, I need to go run composer, install." You run composer install. That's the more common one. You pull down the templates, you render the view. Caleb Porzio: Oh, when you have the component installed, yeah. Matt Stauffer: The view caches @Livewire@Ziggy and then you run composer install, but now you're not getting it. That's the most current one. Yeah. Caleb Porzio: Right, got it. Matt Stauffer: Okay. Sorry. Totally nitpicks and nuance. Are there any other common gotchas for Blade that you haven't covered yet? Caleb Porzio: No. I think those are it. Yeah. The basic layout stuff, little nitty gritty stuff. There's one cool thing that I would like to mention if we have a second. Matt Stauffer: Yeah. Caleb Porzio: This is a little nugget that I forget exists and I recently rediscovered it and was freaking out. Matt Stauffer: Yeah. Caleb Porzio: In Blade Components, I'm not going to backfill all this information for some listeners who aren't intimately familiar with Blade Components, but hopefully if you've been following enough along, this'll make sense. If you have a Blade Component, like @component, user name, whatever, user avatar. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: Again, it's kind of like an include, whatever. And like I said, with including Components, you can pass data in. So maybe you want to pass in the name. Okay? So you have show user profile, whatever, @component user profile. And then you pass in a name parameter and then Caleb Porzio. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: And now when you load it in the browser, everything looks great, whatever. And then in your Blade template for that component, you would have echo money sign name, and it would to that. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: Now let's say that because I'm special in my name, I want there to be an SVG icon like Caleb Porzio with some SVG icon. I don't know what it would be, upload or cloud or something. So to do that, what would I do? Would I hard code that SVG into that string? Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: But then it'll get escaped and it won't actually renders as an SVG. Right? Or what if I want to put a whole chunk of HTML for the name? Right. Okay. Matt Stauffer: Yeah. Caleb Porzio: In Components, there's a concept of slots where you can pass chunks of HTML. You can name them even. The cool thing about Components that I love and I wish Vue had, this is better than Vue. That slots are the same as parameters being passed in. So at any time you can name a slot name or a parameter name and just get rid of the parameter and use a slot and switch back and forth. Matt Stauffer: Uh-huh (affirmative). Interesting. Caleb Porzio: And I do this thing all the time for it and it is way more useful than you think. But at any time you can drop down from the parameters you're passing in to a slot and have a full on place to put in valid HTML with syntax highlighting. Matt Stauffer: Wow. Caleb Porzio: Super nice. Matt Stauffer: Yeah. Caleb Porzio: That's a good note. Matt Stauffer: That's awesome. And that's, I mean, I'm trying to remember what there was some thing in Yield, I think was the same thing or section or something? Caleb Porzio: Yield, yes. Yield has a default. Matt Stauffer: Yeah. Well, it has a default, but I think with the default, and this is true for section two, I think you can either pass the content of the default or section or whatever as a single string, which is the second parameter of the yield or the section. Caleb Porzio: Yep. Matt Stauffer: Or you can do an entire block, which is what we normally do, which is kind of the equivalent to a slot. You're either passing that thing in as a string within the parentheses of the yield, or you're actually doing like a... I don't know if this true for Yield, but for end section. Caleb Porzio: Yes, right. Matt Stauffer: You can also just to section, you just pass the second parameter, which is just the string that is that section. Caleb Porzio: Yes. You can, right. You can say @section pass in a string. Matt Stauffer: It's like the inverse of what you're saying. Yeah. Caleb Porzio: Yes. Matt Stauffer: Yeah. Caleb Porzio: Yields have the ability, you're right. And that is the exact same level of awesome. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: Yields have the ability to have a default. So you can say, "Yield content comma and then some default." But it's useless because there's no way to do HTML on the net and yield for a default. To me, it's like it would be so much more useful. Matt Stauffer: Okay. That's why I was asking, can you do that with Yield? Yeah, okay. Caleb Porzio: You can't. Yes. Matt Stauffer: Yeah. Caleb Porzio: But with section you can, you're right. Matt Stauffer: Well, I wonder if that's when you'd want to use overwrite then? Caleb Porzio: That's when you'd want to use overwrite. Matt Stauffer: Or stop or whichever one overwrites the parent's content, instead of using a Yield, you do a section with content and then the child would just- Caleb Porzio: Oh, dude. I wonder if it does that, if you don't ever need a Yield at the end of your sections, that would be sick, Mr. Matt Stauffer. Matt Stauffer: We'll have to go. We're definitely going to have to do like a whole bunch of like little test runs of stop versus end section versus Yield versus whatever and they all work. Caleb Porzio: Right. Yes. Yep. Matt Stauffer: So, this is fun. So it's funny. Because the next thing on this podcast list is the thing where I talk about the fact that you and I have a shared affinity for Blade templating. And apparently I just forgot and I just talked about at the beginning, so we've already done that. Caleb Porzio: Great. Matt Stauffer: It probably would have made a lot more sense to talk about here when I planned it instead of the beginning. So sorry, everybody. But yeah. So, the last two pieces are, is there anything else you want to talk about the topic and how should people learn more? So let's start with that. Is there anything else other than that great little nugget, which was already kind of basically a part of sort of, is there anything else you want to cover on routing or Blade? Caleb Porzio: Probably one other thing that came to mind really quick, when you @extends, when you're extending a layout, you can pass parameters into the @extends. So this is a common use cases. If your base layout file has a title tag with a default owner happening. Matt Stauffer: Totally. Caleb Porzio: But a lot of pages, you should have a more appropriate title tag. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: My favorite place to do it instead of doing it in the controller or something. My favorite place is at @extendslayouts.app, then an array of keys and values. And the key would be site, name, or title. The key would be titled, duh. Title and then hard code in the title there. So, yeah. That would be one. Matt Stauffer: All right. That's awesome. So are there any good articles or tutorials or in general, just learning resources? If you think that somebody really wants to learn Blade, where would you direct them to go? Caleb Porzio: I would say read through the Blade docs, step one. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: Definitely. And then Laracast is probably the best place to learn it. Matt Stauffer: Yeah. Caleb Porzio: Yeah. I'd go to Laracast and I'd learn about Blade. Yeah. Matt Stauffer: Yeah. Caleb Porzio: Yes. Matt Stauffer: I bet that one of the YouTube teachers probably has some good stuff. So you're looking for something free to start with, go check it out. Because there's a couple of people like Traversy and other people who've started covering Laravel recently. So if you want some free stuff, start there, but Laracast is definitely the canonical place to learn up to date stuff about Laravel. So I'm with you on that one. Caleb Porzio: If you want to dig into Blade Components. So the Livewire documentation has a screen cast section and there, I think this one is actually a paid one. So you have to sponsor me for 14 bucks a month. Matt Stauffer: Ooh. Caleb Porzio: But yeah, I know. But I did a series on extracting out form inputs to custom the new Laravel 7 Blade Components. Matt Stauffer: Okay. Caleb Porzio: And I'm just super jazzed about it. It's so great. Matt Stauffer: Yeah. Caleb Porzio: I'm addicted to it. It's so rare that I come across an abstraction as flexible and expressive and powerful as it is. It's so good. Matt Stauffer: That's awesome. Caleb Porzio: So basically I take a bunch of basically all of when you have like a... especially if you using tailwind UI and you import a text field, it's like 70 dibs with a zillion classes and whatever. Matt Stauffer: Yeah. Caleb Porzio: You can't just go throwing that stuff around your app. So you make all these little custom components for form groups and input types and it's pretty good stuff. Matt Stauffer: Yeah. Caleb Porzio: So check that out if you're into the new Blade Component stuff. Matt Stauffer: Sweet. Caleb Porzio: Yep. Matt Stauffer: Okay. So my personal fun moment for you and in case it sounds to anybody like I'm rushing through, I'm having such a good time talking. I just looked up and realized we're at like an hour and a half. Caleb Porzio: Yeah. Matt Stauffer: So that's why I'm like, "I guess we should keep going." Caleb Porzio: I feel like we were getting rolling in it. I glanced and it said, "45" And I was like, "Oh, boy." Matt Stauffer: Yeah, me too. I was like, "Oh shoot." Yeah. So my personal fun moment for you is I know that at one point in time you were on track to be a personal finance guru of sorts. Is that still something that you... Are you kind of super frugal and super thrifty? And if so, what's the first tip or resource you would give somebody to really think about their financial future? And if not kind of what made you kind of walk off of that space a little bit? Caleb Porzio: Yeah. Right. This could go either way. I think the answer is a little bit of both. Matt Stauffer: Uh-huh (affirmative). Caleb Porzio: Yeah. I was really hardcore into personal finance and specifically the FIRE movement for those listening, Financial Independence Retire Early. Matt Stauffer: Financial Independence Retire Early. Caleb Porzio: Yeah. So I was into that Mr. Money mustache, I'm still a mustachian. Matt Stauffer: Okay. Caleb Porzio: I think, his content is some of the best content on the internet. Yeah. On any topic. So I love him and still do. Matt Stauffer: All right. Caleb Porzio: And I do a lot of credit card hacking still and I am frugal. Yes. I spend more than I did probably, but, no, still frugal. I still live in the same apartment I did when I maybe started or shortly after I started at Titan. Matt Stauffer: Yeah. Caleb Porzio: It's like a two bedroom apartment. I don't know. We have one car, we share a car. I just said to Hannah yesterday. I was like, "I don't think we know a single other couple that shares a car. Not even one." Matt Stauffer: Yeah. Caleb Porzio: We don't live in a city that has tons of public transport and everybody has cars. And anyway, so stupid stuff like that. That, yes, I'm frugal. Matt Stauffer: Yeah. Caleb Porzio: Yeah. But I don't stress about it. Matt Stauffer: Okay. Caleb Porzio: I don't measure stuff like I did before. I'm not- Matt Stauffer: Yeah. Caleb Porzio: But I think it's worth saying that I think there was a one on one we had a while ago when I was first launching my personal finance group brand. Matt Stauffer: Yeah. Caleb Porzio: Called Fancy Finance Man. Matt Stauffer: Mm-hmm (affirmative). Caleb Porzio: And I was picking your brain on whether or not to brand it separately- Caleb Porzio: Picking your brain on whether or not to brand it separately, like what do I do? Do I have a Caleb Porzio Twitter account, and then Fancy Finance Man Twitter account? Because what about all the finance people? Are they going to be like, "Why is he Tweeting about tech?" Do you remember that discussion? Matt Stauffer: I do, but I don't remember what I said. I assume I said you should make them all one. Caleb Porzio: There was a good moment that I sort of look back, if I'm being really... I don't know if narcissistic is a heavy word for it, but if I'm just pretending that this is my memoirs or something, given my current endeavors with programming, and how far I believe that I've come, however far that is, there was this moment where I said, I was like, "Yeah, Matt-" I'm going to mess this up, but you basically said that, "You could totally just be the finance guy in the Laravel community. Nobody's speaking about personal finances at Laracon. You could totally-" you were offering me this path. You were sort of delving into that. Caleb Porzio: I remember saying, "No, I want to be a good developer in my own right," or something like that, something prideful. I don't know, I was like, "No, I can't be known for personal finances. I have to be known for code." You said something like, "Well, that's admirable," or whatever, just probably like all right, shut up. You were like... Yeah. So anyway, I think back on that now, and the finance thing. I ditched the podcast after three episodes, and the programming thing went somewhere. So, that's a moment that I look back on in my head. Yep, the moment I almost became the personal finance guy in Laravel. Matt Stauffer: The personal finance guy. The interesting thing is what I'm most interested for most people, because I want to turn this into a tip for other people, I think what I'm most interested in is to recognize that very seldom do people make their name from purely being just a good programmer period. People make their name from being particularly good with a modifier after that. The particularly good is in teaching it really well, or at a particular tech stack, or at something that the people around them are not particularly good at. Caleb Porzio: For sure. Matt Stauffer: I think that one of the things that's very interesting, is I think there's few people who no matter what they do, just kill it. Taylor's there, Adam's there for sure. I think that you're showing some of the breadth of your abilities like yeah, both of your things are front and they're connected, but you built a Laravel plugin and a JavaScript framework that's getting lots of attention from non-Laravel people. So, that's some breadth, right? I would say for a lot of people a good moment to become known in the community is still to say, "I am the-" blah, blah, blah, "Expert in-" blah, blah, blah, "Space." Caleb Porzio: Sure. Matt Stauffer: That doesn't mean that you're not focusing on being a good programmer, but there are so many programmers out there that stick. It's that like the sticky... It's almost kind of schlocky or sticky or whatever. It's kind of what helps it... You get known as the blah, blah, blah guy, or the blah, blah, blah girl, before you get known as Caleb. I think that one of your intents there was to say, "No, I don't want to be the blah, blah, blah guy. I want to do the harder work of just becoming known as an excellent programmer, Caleb." I think one of the ways that you can achieve that is by choosing instead to give yourself a platform where you talk about many different things, or programming many different things, and show that you have something wise to say about all of them. Matt Stauffer: For example, the 20% Time podcast. I think that a lot of your fame came from the 20% Time podcast, where you and Daniel showed that no matter what topic you broached, you had the ability to be excellent thinking programmers on all of them. So you didn't need the shtick of being, "Hey, I'm the guy who knows-" whatever topic, because you could say, "I'm in a platform right now where I could talk about all the topics." I think that's a great way to do it, if you can do it. The problem is, a lot of people are starting a podcast and not going anywhere with them. So, 100%. You did it in a way that was in line with your values. I think to other people I would say, do it that way if you can, sure. But there is sometimes... Basically, take whatever the route is that you can take to getting known as a good programmer, even if it's a good programmer in X, because once your known as that, you can then explore the fact that you're a good programmer in Y as well. Matt Stauffer: Does that make sense? Caleb Porzio: For sure, yeah. No, it's definitely still good advice. Yeah, definitely. Yep. Yeah, I guess I always pictured- Matt Stauffer: I'm sorry, everyone- Caleb Porzio: It's one of those things that... Let's just say... There's a bias here for people who become successful at something, like save it. Matt Stauffer: Survivor bias? Caleb Porzio: Yeah, survivor bias. Matt Stauffer: Basically, yeah. Caleb Porzio: I'm sure I have that, where I'm like, "No, no. Just go for it." Matt Stauffer: Just do what I did. Caleb Porzio: Yeah, exactly. Matt Stauffer: If you do what I did, you will be successful like I was. Caleb Porzio: Right. Yes, exactly. So, I'm very aware of that at play. I guess the thought process behind it for me where there... The way I saw it was some people get... These are the things that I always have a hard time talking about in the Laravel community, because they're about the Laravel community. But let's just say there's some people at any given Laracon, who manage to be friends with the upper tier of Laravel developers, but they don't have the code, the packages, the work that happens the rest of the year, to sort of back it up. Now that's fine to be friends with anybody, and there shouldn't be this developer elite status, and then rest of the... It's not like that. Caleb Porzio: This is the lens that I sort of view it through. I just knew that I didn't want to be that person who was just friends with people who were really prominent developers. I didn't want that. I don't know, it's something about that that just didn't feel good to me. I want to be someone who's putting in the work too all year. Really sweating it, and talking about stuff, and putting it in so that when this conference comes, I've earned my place at the table instead of just being there because I make good jokes, or because I am good at personal finances. I don't know. Caleb Porzio: I'm not trying to poo-poo on your advice. Its good advice. Matt Stauffer: No, no, no it's fine. Caleb Porzio: That's the way that my brain worked that led me there, I guess. Matt Stauffer: I think it absolutely makes sense, and I think that I'm glad you didn't listen to that advice. Just for anybody listening, I think you did the right thing. Part of what I was actually saying there is I proposed three or four different ideas, I do remember that. I just said, "Do you want this?" You could bubble up. Do you want this? And you'd be like, "Nah," and I'm like, "Okay, cool. That's one less... If you were able to be successful enough in your financial whatever thing that you didn't have to be a programmer, would you want this?" You're like, "No." I was like, "Cool." That helps you get some definition. Matt Stauffer: But somebody who does remind me of what you're saying there is, think about Jonathan Rennick. Jonathan Rennick knows a lot about a lot of topics, and yet he's the database guy right now. He doesn't mind it. He's definitely digging into it, but I don't think anybody who's ever worked with him as a programmer would say, "That guy only knows databases." Caleb Porzio: Right. Yeah, oh exactly. Yeah. Matt Stauffer: Even among super, super talented programmers who have earned their keep, there's a diversity of how much you do or don't want to focus. I think the biggest note here is that everyone should have information, all the information, and then decide what works for them. I'm glad you found what works for you, and I'm glad you didn't listen to my advice about the Fancy Finance Man thing. You're 100% right, and I love the space you're in, man. I'm not feeling rejected at all, and I'm glad you're here. Caleb Porzio: Yeah. Yeah, no that's a fantastic point. He's a good example of somebody who... That's funny, because he's the database guy. He's the Eloquent guy, but he's so much more than that, and has a whole rich history in PHP. That definitely is a good point. Really, if you love it, I mean I love it, and I love it and I love it working hard at it. So, you just do that over a long enough timeline, and certain things stick. Whatever, you find little cool things like if sushi happened before any of this other stuff, maybe I would get into being the guy who fixed Eloquent. Parental happened, and I could have been... I'm not saying I could have been Jonathan Rennick, but there's definitely those things. Just follow the paths that stick, and the holes in the community. Caleb Porzio: The more holes that you could fill... I don't think this is a zero sum game, because my brain goes there, but I know that's not the truth. But I do see friends of mine in other ecosystems where I'll be like, "Oh, there're holes there." We saw it with Adam, him coming into here. Just holes everywhere. These people don't even know about collections. Matt Stauffer: That's so funny because I told one of my friends, I was like, "Yeah, so this guy who works with me, Adam, he's writing this thing about collections and I think it's going to be a really big deal, and I'm super excited about it." He's chuckling. He's like, "Oh yeah, we have collections and rails," blah, blah, blah. I was like, "Okay." So he was basically using that to say Adam's not going to see any success. I was like, "No, this is going to be awesome. You just wait and see." Caleb Porzio: Yeah, wait. Matt Stauffer: Then later he was like, "Well, damn." I was like, "I know. You weren't ready for that." So yeah, there's definitely a lot to be said about that. Caleb Porzio: For sure. Matt Stauffer: All right, that was my personal fun moment. Oh no, you missed the one piece though. Matt Stauffer: If someone were your average American, and I'm sorry everybody else, if you're an average American be it of the age of 20-40, and sorry people outside of the age range, what would you think the first step that they would take towards maybe being a little bit more thoughtful, or protective, or careful, or fiery, or whatever about their finances? Caleb Porzio: The number one thing I would say to do, it's very simple, and it's not too hard, and it has amazing results, click bait. Measure every penny you spend for a month, every single penny that leaves your... If you are a company, every single penny that goes in and goes out of you and your company, measure it, write it down, categorize it, and I believe this more than anything in the world, what's measured is improved. You can't improve something if you haven't felt the pain of how not good it is. A great way to feel that pain is to go through transaction by transaction, and read... I'm dropping Buffalo/Canadian references here. Tim Horton's bagel. Tim Horton's bagel. Tim Horton's bagel. Tim Horton's bagel. $4.50. $4.50. $4.50. $4.50 is not a big deal. Matt Stauffer: Sum that up for a month. Caleb Porzio: Sum it up for a month, wait a minute, wait a minute. I mean, I've had moments where I'll literally go back and check my math for some mental thing- Matt Stauffer: There's no way I spent that much money on bagels and coffee. Caleb Porzio: There's a fortune cookie that I once read that went something like this- Matt Stauffer: Are you going to get deep? Caleb Porzio: No. "Many holes..." I was going thinking of two different fortune cookies. The bad fortune cookie, "The Great Wall didn't got built in a day." And then I would make fun of that fortune cookie a lot, but the fortune cookie I'm trying to say is, "Many small holes sink great ships." Matt Stauffer: Yeah, mm-hmm (affirmative). Caleb Porzio: That is the most true thing I can say about personal finances, is its much less about the big things, although those matter too, but basically if you measure everything for a month you'll feel so much pain from it. You'll also realize... I have a whole category in my budgeting app called BS, the full word, because it has to say the full word to fully express what it means. Basically, I do it when I come across something and I'm mad at it. I go, "This is BS," and I label it that because it's something I signed up for and forgot to close. I just feel like an idiot, and I'm so angry at it. I'll say... Like a friend who looped me into one of their whatever schemes, and I see that transaction show up. Caleb Porzio: Those are the things that you miss. If you never look at every transaction, you miss all the ways you're bleeding out. Then there's the bigger obvious things like kill all your debt. This is the moustaching thing, is like the root of all financial problems for everybody in America is cars, because they make you fat, they make you diseased, you die early, they weigh on our healthcare system, they also weigh on our environment, and they weigh on your pocketbook, first and foremost, because you buy new cars, and you spend way too much, and you have debt, whatever. Cars is a huge one. Caleb Porzio: Yeah, then houses and all those things, I don't know. But that's my thing, is what's measured is improved. Measure everything for a month. Matt Stauffer: I love that. Caleb Porzio: Feel the pain of those bagels, and you will improve, and you will get clarity. After that, you will be motivated. That's what I got. Matt Stauffer: I love it. Tim Horton's, that's my shortcut to the whole thing. Caleb Porzio: Tim Horton's. Matt Stauffer: Watch for the Tim Horton's. Okay, so you have a million projects going on. I'll link all of the stuff that we've talked about in the show notes, but you've also got some sponsorship opportunities. Let's talk real quick, how can people follow you? What do you want to plug? How can they support you and what you're doing as an open source maintainer? Caleb Porzio: Sure. Livewire and Alpine are my things. It's now being branded as the tall stack, Tailwind, Alpine, Live Wire. What is it, tallstack.com? Matt Stauffer: Yeah, tallstack.dev, I think. Yeah. Caleb Porzio: Tallstack.dev. Matt/Titan folks put together tallstack.dev. Matt Stauffer: I just wanted to play with Tailwind UI one day, and I was like, "All right, Tall Stack it is." Caleb Porzio: Cool. Yeah, so those are my things. If you're into that stuff, and you're into my stuff, that's great. Twitter's the best place to follow me day to day. I try to tweet fun, useful things I tweet, or whatever. The other project that's kind of out of left field is my VS Code course. It's this totally not related to anything else... Well, actually it's related to everything else because every programmer uses an editor, and a lot of them use VS Code. VS Code is, I'll say, broken in a lot of ways out of the box. It's great, and that's why I use it. But there are so many frustrations, so many little frustrations. Also, just develop a workflow... I guess I've just my workflow over a long time. I started tweeting about it and enough people were interested, so I started a little email list. Caleb Porzio: If you're into that, go to learn-vscode.com to get on that email list. There's a ton of good content you'll get right away. Every other day you'll get an email, and there's seven really good emails. But now, I've sort of stopped those and I'm building an actual course. I'm writing 1,000 plugins, and I'm in the weeds of the Valley of Despair with this course, but the draft is written. I have all the drafts for the plugins written. I want to fix VS Code for specifically for Laravel developers, but for everybody. That's another thing to tune into. Caleb Porzio: The last thing, sponsoring. That's my main... Actually, now it's my primary source by far of income, is GitHub sponsors. I realize getting in all this that open source does not pay you anything. Matt Stauffer: Turns out. Caleb Porzio: You sort of think that people who have successful open source projects just somehow get a lot of money. But it's not true at all. So, I'm trying to change that with GitHub sponsors by offering lots of things with that. You get access to screen casts and source code, and whatever. But yeah, so sponsor me to support the work if you like the work. That's that. Matt Stauffer: Yep, and the links to that and all the other things we've talked about so far will be in the show notes, so you can check them out. Caleb, thank you so much for your time. This was a ton of fun. Of course, we ran late because there was way too many things to talk about, and half of these could have taken the extra hour. I really appreciate you joining me, all the things you're doing for the community, and yeah man, thanks for hanging out. Caleb Porzio: Thanks for having me. It's a blast. Matt Stauffer: All right, see y'all next time. Caleb Porzio: We're now recording. Let me call Aaron. Aaron: Mr. Caleb, or maybe Hannah. Caleb Porzio: Mr. Aaron. Hannah's here in secret. Caleb Porzio: Aaron, I am recording an episode of the Laravel podcast. Matt Stauffer, who hosts it, is having me on. I'm looking through these prep questions, and one of them is "Let's start with routing. If you had to describe the routing in a web app to a five year old, how would you do it?" I thought, well why don't I call an almost five year old, and see if I can explain it to him. Do you have an almost five year old- Aaron: So you're saying I'm a five year old? Or do you want me get one of my kids? Caleb Porzio: I would like a child that's closest to the age of five. I would love to try to explain Laravel routing to him, if he's around. Aaron: Uncle Caleb needs to talk to you about something. Here, Sam. Say hi. Sam: Hi, Uncle Caleb. Caleb Porzio: Sam, how's it going? Sam: Good. Caleb Porzio: Sam, I have a question for you. I need to try to explain the way websites work to someone. Do you know how websites work? Sam: I think I do. Caleb Porzio: Sam, do you know what a website is? Sam: I've heard that before, but I don't know what it is. Caleb Porzio: Okay, do you ever go on the iPad and look at stuff? Sam: Yes. Caleb Porzio: Yeah, what do you do on the iPad? Sam: I don't know. Umm...like...call Aunt Hannah Caleb Porzio: What's that, Sam? Sam: And he's call to Aunt Hannah and it's like it comes to Aunt Hannah. Caleb Porzio: So you go on the iPad to talk to Aunt Hannah? Sam: No, Danny does. Caleb Porzio: Oh, Danny does. Have you heard of Google? Sam: Yeah. Caleb Porzio: Do you know what Google does? Sam: What? Caleb Porzio: Do you know what Google does? Have you ever used Google, Sam? Sam: No. Caleb Porzio: No. Sam, have you ever used a computer before? Sam: Yes, I type. Caleb Porzio: Oh, you do- Sam: Like dad. Caleb Porzio: You type on a computer? Sam: Mm-hmm (affirmative). Caleb Porzio: What kind of computer? Sam: We make words and I...We make words and I say what they are. Caleb Porzio: Oh, so he types what you tell him to? Sam: Yeah. Caleb Porzio: Okay, nice. That's great Sam. I think that's all I needed to know. I just wanted to know if you knew how to use computers, and I wanted to talk to you about it. So, that's actually it. Sam: Bye. Caleb Porzio: Bye, Sam. Thanks. Aaron: Was he supposed to say goodbye? Caleb Porzio: Yeah, yeah. Aaron: Okay. Caleb Porzio: I think the routing thing's not going to work for- Aaron: You want the older one? Caleb Porzio: I want the seven year old. Seven, right? Aaron: Yeah. You got to talk to Uncle Caleb about computers. Danny: Hi. Caleb Porzio: Dan-O, how's it going, Dan? Danny: Good. Caleb Porzio: Dan, I'm recording a podcast later today, and I need to talk to you about websites, because I need to know how to explain websites to a kid who is like seven years old. You're seven, right? Danny: Yes. Caleb Porzio: Okay, so can I just ask you some questions about websites? Danny: Sure. Caleb Porzio: First, do you use the computer ever? Danny: Sometimes to write stories. Caleb Porzio: Okay, do you ever go on Facebook or Instagram, or anything like that with your mom or dad? Danny: No. No. Caleb Porzio: Do you ever answer quizzes with your mom? Danny: Sometimes. Caleb Porzio: When you're answering the quizzes, explain to me how it works. You see a question, and then you click a button to answer it or something? Danny: Yeah. Caleb Porzio: How does it work? Danny: It gives you the question. There's five different options. You hit a button. At the end, it tells you your score or something. Caleb Porzio: Okay, gotcha. All right, so basically what I'm doing is I'm trying to figure out how to explain to people what web apps are. Have you ever heard the word "Web App"? Danny: No. Caleb Porzio: No, so your dad and me, we're programmers. You have seen him program and stuff? Danny: Yeah. Caleb Porzio: We program web apps, which are basically just websites. So, when you're using that quiz, you're using a web app. Does that make sense? Danny: Yeah. Caleb Porzio: Okay, what I'm supposed to explain is how routing works. Routing is just a fancy word, but this is the whole point of this, is I'm trying to figure out if I can explain routing to a seven year old. So, are you ready? Can I explain routing to you? Danny: Yeah. Caleb Porzio: Okay, so get ready. I need you to get your thinking cap on. Tell me when your thinking cap is on. Danny: Ding. Caleb Porzio: Okay, got it. Was the noise that it makes when you put it on? Danny: Yes. Caleb Porzio: Awesome. Okay, so here's what routing is, basically if I have a web app, like a quiz app, that you go on and you click buttons to answer the quiz, when you click a button what you're doing is you are telling the web app's routes... You're basically telling the web app's router to do something, and then usually that something shows you an answer, right? Like after you click the quiz answer, it shows you an answer? Danny: Yeah. Yeah. Caleb Porzio: Inside of web app, if that quiz app is a web app, and a web app is a little machine, when you click a button the router is the thing that actually does the "thing". It's the thing that processes your answer and tells you if it was right or wrong. Does that make sense? Danny: Mm-hmm (affirmative). Caleb Porzio: So it's kind of like telephone numbers for a website. When you're on a website and you click on something, the router is the thing that knows where to take you. Does that make sense? Danny: Yeah. Yeah. Caleb Porzio: Okay, can you try to explain routing to me? Danny: Yeah. So, when I'm doing quizzes, when you hit a button it tells the iPad, computer, phone thing, the technology, to do something. At the end, it tells you what it is. Caleb Porzio: Nice. So, which part is the router? Danny: The router for quizzes, is when you hit the button- Caleb Porzio: Nice. Danny: And it tells the thing what to do. Caleb Porzio: Danny, you're a genius. That's it. You got it, Dan. I just needed to know if I could do it, and if you could do it. And you did it. We did it. Danny: Yay. Caleb Porzio: Sweet. Thank you for being a genius, Danny. Danny: You're welcome. Caleb Porzio: Okay, I'll be seeing you.