In this section, I describe the three most common design pitfalls that I encounter in AngularJS 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 AngularJS and the MVC pattern can provide.
1. 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 views, rather than in controllers
- Putting domain logic in controllers, rather than in 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).
■ Tip 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. I describe the AngularJS support for unit testing in Chapter 25.
Knowing where to put logic becomes second nature as you get more experience in AngularJS development, but here are the three rules:
- View logic should prepare data only for display and never modify the model.
- Controller logic should never directly create, update, or delete data from the model.
- The client should never directly access the data store.
If you keep these in mind as you develop, you’ll head off the most common problems.
2. 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. I recently worked with a project team that had built their client so that it honored the data format quirks of their server-side SQL server. The problem they ran into—and the reason why I was involved—was they needed to upgrade to a more robust database, which used different representations for key data types.
In a well-designed AngularJS 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.
3. Clinging to the Old Ways
One of the most powerful features of AngularJS is that it builds on jQuery, especially for its directives feature, which I describe in Chapter 15. The problem this presents, however, is that it makes it easy to notionally use AngularJS for a project but really end up using jQuery behind the scenes.
This may not seem like a design problem, but it ends up distorting the shape of the application because jQuery doesn’t make it easy to separate the MVC components, and that makes it difficult to test, enhance, and maintain the web app you are creating. If you are manipulating the DOM directly from jQuery in an AngularJS app, then you have a problem.
As I explained earlier in the chapter, AngularJS isn’t the right tool for every job, and it is important you decide at the start of the project which tools you are going to use. If you are going to use AngularJS, then you need to make sure you don’t fall back to sneaky jQuery shortcuts that, in the end, will cause endless problems. I return to this topic in Chapter 15 when I introduce jqLite, the AngularJS jQuery implementation, and throughout Chapters 15-17, when I show you how to create custom directives.
Source: Freeman Adam (2014), Pro AngularJS (Expert’s Voice in Web Development), Apress; 1st ed. edition.