Production-Grade Angular

App Boilerplate & Components Overview

Production-Grade Angular

Check out a free preview of the full Production-Grade Angular course

The "App Boilerplate & Components Overview" Lesson is part of the full, Production-Grade Angular course featured in this preview video. Here's what you'd learn in this lesson:

Lukas starts working on a new application that generates widgets, gives an overview of the application boilerplate by exploring the routing code, the api-interfaces code, and the logic within the widgets component.


Transcript from the "App Boilerplate & Components Overview" Lesson

>> I am now in the repository that is on the GitHub repo. So what I'm gonna do from here is I am going to check out the boiler plate branch. So this is 0.1 dot one hyphen boilerplate. So this is going to save us maybe 40 minutes, and it's going to allow us to talk about a lot of other more interesting things.

So from the command line Git checkout, let's go 1.1-boilerplate, there we go. And I'm gonna go npm run, serve all, and hopefully I didn't do something wonky that I forgot about, but this should do fairly well. Let's see, so I'm getting an error in my API, but I don't think that matters too much.

So. All right, good, so the application that we generated in the previous module, I generated a home component. And I generated a widgets component that has a widgets list and a widgets detail. So take a quick tour of this, just so we can see what we are dealing with.

So if I go to our routing module, so you'll notice when I started talking about angular applications, I started really kinda make a routes. Because I think when you look at your feature map, typically, a feature gets a route, in this case, we have a single feature, which is widgets.

So I have a widgets route that points to the widgets component. And then typically I will have like a home component that allows me to composite multiple things together. Like if I had items then I could show items on there, or I could show widgets or whatever it may be.

And then from here, if I go to the home component, all I've done is I've hard coded an array of widgets in here. And you'll notice that I'm typing this and I'm pulling this from the API interfaces. And then if I go to the widgets component Here Similar thing, mock widgets, and I have an empty widget.

And from here, I'm just doing some basic manipulation stuff like if I create, I'm just adding it in to the array concatenating it, if I'm updating it I'm just looking for the one on one update and replacing it and I'm filtering. So, this is pretty standard CRUD operations and now one thing that I will point out the question is on container components, what kind of logic would you have in there?

Well, one thing that you could do is if you look in your code, so typically if you're updating, or creating something, your form is gonna be exactly the same. And so if I'm creating a new and I don't know if this will work, but if I'm creating something, I'm using the same form that I would to update it.

And so in order to reuse that component in my container component, typically what I'll do and because this is, I think very particular to the presentation of that component in it's like local presentation logic. Is then say if this has an id, it exists, so go ahead and update it.

If it doesn't, then it's a new component, go ahead and create it. And so this is typically the amount of logic that I will have in a component. Everything else other than this kind of Quazi transition code that we're going to move away from is very, very simple.

I'm either calling another method or I'm accepting a parameter and assigning it to something else, and so you'll notice these are very, very thin. I mean, even kind of my fake code in here, very, very thin. If we go to, The widgets list component, now we have a presentation component, and notice here, even thinner, razor thin and so all this does is takes widgets and then it takes a flag is it read only or not.

And then if you select or you delete a widget, then it just surfaces that up, which then goes back into your parent component. And then ultimately, you do something with it. So what I want to just call out here Is that our components are super thin, they're not doing very much, and all we're doing is we're consuming data, and we're capturing events.

So, on the presentation components, they're not doing anything, what this means is. Even at a micro level, what we're seeing here is that in the home component and in the widgets component. I'm able to pick up the widgets list and move it around across these two kind of what I would consider container components.

So this is something that we do kind of intuitively, like we use components all over the place. But the fact is because we've abstracted this. Now this widgets list is very portable, as demonstrated by the fact that we're able to move it into the home component. Because all of its dependencies are being fed into the component as an input.

So remember I talked about tier immutable functions, that everything that you need you pass into it. Well this same principle applies to the components at the component level and component-driven architecture. So just behold the thinness of this. And if I go to, I think maybe there's one more Thing that maybe I'll show you that, within this, we have a toolbar, and then we have this container that has kind of the nav, and the different things here.

So this is our router outlet. Super simple, basic angular application up to this point. So we have two routes, home widgets, and a master detail view.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now