But what if there were a whole class of apps that didn't need this power and flexibility? I call these Single Component Apps, and I build them every day.
Here's two examples that I built or worked on recently:
- update.angular.io - the interactive Angular update guide
- baby.fluin.io - an app I built for tracking my infant son
I'm also working on several others (like my Hex grid game) that will ship eventually.
How they workGenerally I have a single template with a lot of containers and divs that look like this:
<ng-container *ngIf="data | async as result">. With
ng-container, and a liberal use of
*ngFor, you can probably build most single screen applications.
Ignoring parts of AngularEach of these applications uses a single component, meaning it's ignoring huge swaths of the Angular API.
I can use any of the features I want, but I don't feel compelled to use them until they make sense. This helps me avoid over engineering. I can naturally create services, pipes, queries only when I feel the need, creating an application that I can iterate quickly on in the beginning.
Better than Vanilla JSThese apps aren't sophisticated, and I could have built them with Vanilla JS, but then I would be writing a custom DOM manipulation / rendering methods, when the look and feel of a declarative template really meets my needs and make sense to me.
Angular is valuable in these apps due to the template syntax, change detection, pipes. It's also valuable simply due to the awesome build system that you get out of the box with the Angular CLI. TypeScript, minification/uglification, great live reload, and more all come by default.
But why not use multiple components?If you need multiple components, go for it! As each of these applications grow, I expect I will eventually want to extract out some of my rendering logic and in the long run, components are fantastic for isolating parts of your application and making your code more reusable, and easier to reason able.
I generally like to start with a single component until its template violates DRY principles, or until it starts being a couple hundred lines of code.
If I ever want routing in these apps, I'll also go for components, as the Angular Router is wired for this functionality out of the box. Additionally, file level separation between routes is very logical.