In this section, I describe the three most common design pitfalls that I encounter in Angular projects. These are not coding errors but rather problems with the overall shape of the web app that prevent the project team from getting the benefits that Angular and the MVC pattern can provide
Putting the Logic in the Wrong Place The most common problem is logic put into the wrong component such that it undermines the MVC separation of concerns. Here are the three most common varieties of this problem:
• Putting business logic in templates, rather than in components
• Putting domain logic in components, rather than in the model
• Putting data store logic in the client model when using a RESTful service
These are tricky issues because they take a while to manifest themselves as problems. The application still runs, but it will become harder to enhance and maintain over time. In the case of the third variety, the problem will become apparent only when the data store is changed (which rarely happens until a project is mature and has grown beyond its initial user projections).
Getting a feel for where logic should go takes some experience, but you’ll spot problems earlier if you are using unit testing because the tests you have to write to cover the logic won’t fit nicely into the MVC pattern.
Knowing where to put logic becomes second nature as you get more experience in Angular development, but here are the three rules:
• Template logic should prepare data only for display and never modify the model. • Component logic should never directly create, update, or delete data from the model.
• The templates and components should never directly access the data store. If you keep these in mind as you develop, you’ll head off the most common problems.
Adopting the Data Store Data Format
The next problem arises when the development team builds an application that depends on the quirks of the server-side data store. In a well-designed Angular application that gets its data from a RESTful service, it is the job of the server to hide the data store implementation details and present the client with data in a suitable data format that favors simplicity in the client.
Decide how the client needs to represent dates, for example, and then ensure you use that format within the data store—and if the data store can’t support that format natively, then it is the job of the server to perform the translation
Just Enough Knowledge to Cause Trouble
Angular is a complex framework that can be bewildering until you get used it. There are lots of different building blocks available, and they can be combined in different ways to achieve similar results. This makes Angular development flexible and means you will develop your own style of problem-solving by creating combinations of features that suit your project and working style.
Becoming proficient in Angular takes time. The temptation is to jump into creating your own projects before understanding how the different parts of Angular fit together. You might produce something that works without really understanding why it works, and that’s a recipe for disaster when you need to make changes. My advice is to go slow and take the time to understand all the features that Angular provides. By all means, start creating projects early, but make sure you really understand how they work and be prepared to make changes as you find better ways of achieving the results you require.