Hey, everyone, welcome to Developer Tea. My name is Jonathan Cutrell, and in today's episode, I'm going to be talking to you about three ways you can improve your views. Today's episode is sponsored by Linode. With Linode, you can instantly deploy and manage an SSD server in Linode Cloud. You can get a server running in just a few seconds with your choice of Linux distribution, resources, and node location. We will talk more about what Linode has to offer to you as a Developer Tea listener later on in today's episode. But first, I want to jump straight into this discussion about views. You know, you spend a ton of time, especially if you're a web developer. You spend probably a ton of time in your views. If you're working with Rails, you have a folder full of these views. And anywhere that we spend a lot of our time is a place that we should be thinking about getting better. And the reason for that is because over the course of our career, if we spend our time in views 50% of our day, right, if we're spending a lot of our time working on views, then the better we can deal with the problems that views present, the better we can deal with those problems, the more time we can save in the long run, right? Where we're experiencing issues with views every single day. Now, if you are not familiar with the term view, essentially what a view is is a data rendering set of markup, some kind of markup, some kind of representation of the data rendering. In the traditional MVC structure, the model view and controller, the view is responsible primarily for the interface. Now, I do want to mention a point of clarification. Depending on your tech stack, this concept of view may be labeled something different. For example, you have a view controller on iOS, and that's not really what we're talking about. We're talking about the template, something that acts kind of as a shell that shows the data that you pass to it. So I want to talk to you about three ways you can make your views better. You know, the most common problems that we see with views is the difficulty to maintain those views over time. We see a lot of code duplication. And sometimes we quite honestly just see very complicated code in the views. It's difficult to maintain because the code becomes very complicated. So we're going to talk about ways to reduce some of these issues. The first concept I want you to think about to improve your views is single responsibility view creation, single responsibility view creation. You may also consider this single responsibility partials or composable views. These are all different ways of talking about the same concept, which is really create views that have only one purpose, create views that have only one purpose. Now, I'm not saying to create a view that can't be reused. In fact, I'm saying quite the opposite. If your view only has one purpose, then it can be composed with other views. And it can be reused with different types of data. If your view is not combining multiple specific things together, for example, let's say you have an index of objects, we'll use the example of cars today. Let's say you have an index of cars, and you've created a view for that. And you create the top meta information and the menu, and you put all of that in a single view file. You put all of it in one file. Well, now that file is only useful for your car index. OK, let's think about that for a second. What can you do to fix that problem? Well, of course, you can take out the menu, put it in its own view. You can take out the index element, that list of cars, whatever that is rendering. But we can even break this down further. We don't have to look at the entire collection and create a view that wraps that entire collection as the lowest level view. We can also go so far as to create an individual element in a collection. You could even have a button view for your menu, for example. The further you break down your views, the more simple those views are, right? The more singular their responsibility, the more composable they will be, the more flexible they will be. You'll be able to put them together in any way that you choose. So get focused on creating single responsibility views, create single responsibility views, just like you create single responsibility classes. Now, today's discussion will lean a little bit towards the object-oriented side of programming, because this is where we see those types of problems surfacing most often. So that first thing that you need to keep in mind to improve your views is to create single responsibility views. We're going to talk more about ways of improving your views. We have two more items right after we talk about today's sponsor, Linode. Linode has eight data centers with plans to start at $10 per month, and you can get a server running in under a minute. Linode has hourly billing, a monthly cap on all of their plans, and add-on services. For example, backups, no balancers, and long view. You can have a VM for full control. If you want to log in as root, you can run Docker Containers. In fact, today I spun up the Linode Lamp stack on my local machine in just a few minutes. You can have encrypted disks, VPNs. You could even run your own private Git server on Linode. They have native SSD storage for those of you who are worried about speed on the internal network. It's a 40 gigabit network. And those actual SSDs are running on top of Intel E5 processors. On top of all this, Linode has a seven-day money back guarantee. And just for being a Developer Tealistener, Linode is offering you a $20 credit at checkout. $20 just for using the special link that you can find in the show notes, Linode.com slash Developer Tea, or you can use the code Developer Tea 20 directly at checkout. That gives you $20 of credit, which is equivalent to two free months at their starter plan. So go and check it out, Linode.com slash Developer Tea. Thanks again to Linode for sponsoring the show. So we're talking about ways that you can improve your views. The first way was to create single-responsibility views. Don't try to combine responsibilities into one view. Go ahead and separate those out into their own files. Use partials if your particular tech stack allows you to do so. The second concept that I want you to be thinking about when you're writing views is the child instance substitution test. The child instance substitution test, basically what this says, is render your view. And when you're trying to make your view a little bit better, a little bit more organized, go ahead and load up an instance of a child class wherever you're calling methods on an instance of a class in your view. So let's say that you had that index of vehicles. And they could be cars, they could be trucks, they could be anything. You have an index of vehicles. Try rendering that same index with a child class. So not vehicle, but maybe the car or maybe the boat. You can try rendering it with that child class. And the idea here is twofold. Number one, it's going to make your classes more organized. It's going to make your classes more organized. Secondly, it's going to make your views more reusable and more organized as well. This practice will naturally simplify your classes. And it will limit the number of things that you're doing in your view that are class-specific. It'll limit the number of things that you're doing in your view that are class-specific. This makes your views significantly more readable and much more composable, much more reusable in the long run. So again, try that child substitution class. Whatever view you are loading up, perhaps it's a list of model instances or maybe it's only one model instance, but try loading a child class, something that inherits from what that view was initially intended to portray, load an instance of a class that inherits from that class with the same view. So number three, we've gone through number one, single responsibility views. Number two, the child substitution, that's child instance substitution test. Remove all of the if statements. This is the most difficult of the three by four. Remove all if statements from your views. Now, you may immediately think that this is kind of ludicrous or it's impossible, but removing the if statements from your views reduces the complexity of those views. And you'll find that it will help you in the first two tasks that I've asked you to already complete. If you remove the if statements, in fact, I would say start by removing the if statements in your views. What you'll recognize that you're going to do is start putting the logic that you otherwise would require in the view in a different place. You still need the logic somewhere, but if you take it out of the view, the view becomes agnostic to that logic. And that's exactly what we're trying to do to make these views more reusable, to reduce complexity and to make them much more readable and maintainable. If you remove the if statements, if you remove the logic out of that view, it's going to become immediately much more readable, maintainable, all the things that you want out of your views. That's how you improve your views. So you may be asking, hopefully you are asking, how do I get the if statements? How do I get the logic out of my views? Again, you hopefully are already thinking, well, maybe I can put it in a controller, or maybe I put it in a model, or maybe I'm putting it in something like a presenter class. There's a lot of debate about whether presenter classes are the proper answer. I recommend you go and listen to a talk by Sandy Metz. It's called Nothing Is Something. And she presented at RailsConf 2015. It was a fantastic talk. I was actually in the audience for that talk. And she talks a little bit about this concept, specifically pay attention to the null object pattern. This is going to help you out, particularly if you are a Ruby developer, you're going to be able to see a lot of the patterns that she is presenting. But just about anybody who codes on a regular basis can get a lot of value out of that presentation. It will help you to start thinking about ways that you can remove logic from your views. Thank you so much for listening to today's episode of Developer Tea. And then you can again, to Linode for sponsoring today's episode. And forgiving everyone who's listening, $28 of credit. Just by using the code Developer Tea 20. Plan start at $10 a month, go and check it out. Linode allows you to instantly deploy a manage and SSD server in the Linode cloud. Go to Linode.com slash Developer Tea or Developer Tea 20. Use that code. Of course, that will be in the show notes at spec.fm. If you are enjoying Developer Tea, make sure you leave a review in iTunes. This is the best way to help other developers find Developer Tea. But it's also the best way to help the show out, to help us keep on doing what we do on regular basis. So thank you for leaving those reviews. It's hugely appreciated. And I read every single one of those. Make sure you subscribe to the show in whatever podcasting app you use so you don't miss out on the next episode of Developer Tea. Thanks for listening. And until next time, enjoy your tea. Take good care of yourself.