Page 72 - MSDN Magazine, May 2017

The Working Programmer TED NEWARD How To Be MEAN: Angular CRUD
Welcome back, MEANers.
Last month I explored Angular components—modules, compo-
nents, services and others—in preparation for a deeper dive into how to create some of those components (msdn.com/magazine/mt795191). So let’s start applying these component concepts to something
more practical.
Command-Line Tooling
Before I get into the component concepts, there’s just one side note I want to make. Some readers e-mailed me to ask if the Git project was the only way to get started with an Angular project; they expressed dubiousness at the idea that this was the only way to get started. As they well suspect, that’s hardly the case. Angular makes available an npm package called angular-cli that can get the bare- bones structure in place. Using it is straightforward: install, run the generator, answer a few questions and go:
npm install -g @angular/cli ng new my-app
cd my-app
ng serve
This will create a new application in the my-app subdirectory and ng serve will effectively do an npm start and kick off a long- running process to run the Web server locally and transpile files as they’re edited.
The starting point for a new component is to create it.
Whichever approach you use, you’ll end up with a scaffolded “hello world” application; but keep in mind, by the time your proj- ect starts to see serious coding, much of that scaffolding will get modified/replaced. So, the actual path you use to get started won’t make much difference in the long run. Use whichever approach feels more comfortable.
Components
When thinking about how to structure a visual application—be it a traditional GUI desktop, a server-based Web application or an SPA application—it helps to think about the application in terms of the identifiable “parts” that can come to mind. Most applications, for example, have a discernible header or footer, usually some kind of menubar or menu structure, and a more generalized content area. Then, within that, there are smaller breakdowns, depending on the
goal of the application and the constituent domain entities. One such breakdown is the traditional “master-detail” UI approach in which a user first navigates to a large (usually searchable) overview list of domain entities, selects one and moves into a detailed view of that domain entity. Often, that detailed view can be flipped be- tween read-only and editable states through some kind of button or switch, usually defaulting to a read-only view to start.
The key to all of this is to think in component terms: Where are the convenient boundaries? In the case of an application that wants to display the speakers giving talks and let users of the application offer their feedback, the components are fairly obvi- ous. (As with most written examples, they’re designed to be.) A few components will be trivial to write—and thus make good first steps—owing to the fact that they involve no user input or editable state, and a few will be a bit more complex, as they’ll likely require both input and reaction to changes in state. The key across all com- ponents is a high degree of coherence: The component should basically be a tightly fitting “whole” that represents a “thing,” what- ever that “thing” might be.
I’ll start by defining that “thing” as being a simple footer component that will display a copyright message containing the current year.
Copyright
Now, it’s time to start working on the first component. Assuming you’ve got a cleanly scaffolded project (meaning you’ve thrown away the GreetingsComponent you did last time), you want to build out a new UI component to display a footer at the bottom of the application’s main page. Ideally, this component should display “Copyright (c) (current year), (your company)” across the page, wherever it appears. The assumption is that the users of this com- ponent will put it at the bottom of the page, but it’s entirely possible that some odd UI/UX quirk will require something to go below it (perhaps legal disclaimers?), so let’s not make any strong assump- tions about where it will appear on the page.
The starting point for a new component is to create it. While there’s always the option of creating files and directories by hand, I like tools that will do the repetitive stuff for me. So I’ll lean on the angular-cli ng tool again, and this time, ask it to generate a component for me:
$ ng generate component footer installing component
create src/app/footer/footer.component.css create src/app/footer/footer.component.html create src/app/footer/footer.component.spec.ts create src/app/footer/footer.component.ts update src/app/app.module.ts
66 msdn magazine