AngularJS Components and Staying Relevant

Before I start, AngularJS means version 1.x and Angular means version 2+.

Angular threw everyone for a loop when it completely changed the structure of Angular applications by introducing components and favoring them over controllers and directives. There’s several other things but this is what’s relevant to this article. With the introduction of components, the Angular team embraced what seems to be the “new” standard in frontend development. Which is to build things using “component based practices”, with the main theme being isolation and reusability. For the record, this is not a new paradigm ;).

The introduction of components was a pretty big change in the Angular world; however, this practice was already adopted by other frameworks such as Ember and React. To introduce the practices to the AngularJS community, the notion of a component was introduced in 1.5.

Some of the perks of writing components include:

• Easier testing. Writing unit tests are a way for us to feel comfortable with the code we write. Most of your methods in your components should be single purpose and descriptive, making each unit test concise and easy to read. We use Karma for our testing environment and Jasmine for our testing framework. While it’s not full end to end testing, it still gives us some confidence.
• Separation of concerns and decoupled code. The input/output pattern requires you to be deliberate and thoughtful about your components purpose. If a component you’re writing is becoming too complex, step back and think if you should be breaking it up into multiple components.
• Built in life cycle hooks and using inputs/outputs consistently will give developers a place to look for what gives life to your components.
• Preparation for Angular and other frameworks. Thinking of things with the component paradigm in mind will prepare you for modern front end implementations that aim to avoid bloat, promote testability, and reusability.

But how do we stay relevant?!?!

Upgrading to Angular is daunting and unrealistic for most organizations. For projects that can take the time to halt feature development this is an option. Most companies can not afford to do that. Feature development must continue and shaking up the day to day development job is a no no. For CallRail’s case:

• We have 20+ developers working on a Ruby on Rails 4.2 and AngularJS application using the asset pipeline.
• We serve up over 1,000,000 page views a month.
• Our AngularJS code consists of 131 directives, 53 controllers, 61 factories, 46 filters, 26 services, and 315 templates.
• We use rails templates to bootstrap our application. We inject erb as needed in our javascript files, although we discourage it. We have some single page parts of the application. You get the picture, there’s a lot of moving pieces.

Realistically upgrading to Angular will only happen when we find a solo project to use it with. If the time comes, the components can be migrated to Angular. The main idea is that introducing AngularJS components at least moves the needle in the right direction. But in the meantime, following best practices, unit testing, and staying on top of the game is a great start.