I do love and appreciate jQuery. It is a great tool for DOM manipulation. However, it is not a tool for building interactivity as a native component of web applications and is definitely not considered a framework. Consider a scenario where we are building a web application using AngularJS and have been using jQuery for a while now.
Wait! I can just use a jQuery selector, grab a DOM element and attach to an event. What’s wrong with that?
As you read, we’ll walk through how to think in AngularJS while providing guidelines to consider when coming from a jQuery background. We will take a different approach to web application building and declare our functionality alongside our HTML in the DOM while modularly-organizing code.
1. Architect our web application
We have to think about how to divide our application into individual, extensible, testable components (modular). We will focus on the functionality that may occur both client-side and server-side as well. AngularJS allows us to do so by providing web application components. Let’s look at our AngularJS web application:
- THE VIEW IS THE CONTAINER OF INTERACTIVITY AND DATA
- HTML, directives (functionality) and data are all declared in the view
- DISTINCT MODEL LAYER
- In jQuery, the DOM can be thought of as the model. But in AngularJS, we have a separate model layer that we can manage, completely independently from the view.
- USE TWO-WAY DATA BINDING TO DRIVE DOM MANIPULATION
- With our data now declared in our view, we will drive the view by allowing AngularJS to bind the data. Views are tied to models (via scopes). Views become a projection of the model.
- SEPARATION OF CONCERNS
- We now have a view to show us our functionality and present data as well as a model to represent our data. AngularJS also provides a service layer to perform reusable tasks. We can now augment our view with AngularJS directives and glue it all together with controllers.
- DEPENDENCY INJECTION
- Tell Angular what we need to operate our web application, and, as long as Angular can find it, Angular will handle loading it for us. This will allow for better testability of our web application.
2. Stop touching the DOM! Please?
I asked nicely, right? Let’s decouple by allowing AngularJS to use the data to drive the functionality. Rather than building a page to manipulate, we interact with a data object (called $scope). When we want to change an element in our view, we change the data that is tied to it and let AngularJS take care of updating the DOM.
3. Declare functionality with the HTML
HTML is written to declare the DOM to the browser. AngularJS continues this tradition and allows us to be declarative regarding functionality.
4. Test Your Application
Because you’re not Chuck Norris! Chuck Norris’ code tests itself…and it always passes…with 0ms execution time!
One of the greatest features of AngularJS is that it was built to be testable. Writing tests not only guarantee that our web application is working, but also that modules/components we are using work as expected. AngularJS was built with test-driven development in mind, and thus, it is incredibly easy to write testable applications. We can write tests for all parts of our application – for the model layer, the service layer, the view layer, etc.
5. Don’t treat Directives as packaged jQuery
Directives aren’t just collections of jQuery-like functions. Directives are actually extensions of HTML. If HTML doesn’t do something you need it to do, you write a directive to do it for you, and then use it just as if it was part of HTML. Directives are applied in the view, so intent is clear and declared.
Think before you reach for the $ and allow AngularJS to do the heavy lifting. Try to focus on the view and look less to DOM elements. Energize your web application with functionality using directives and not event bindings. Think of AngularJS more as a framework and try to think declaratively rather than imperatively when you are coding your web application.