Technology

Web Apps

Angular Components: A Simpler Convention

May 26, 2016

Travis Luong

By Travis Luong

There used to be no single standard for structuring Angular apps. Angular provided us with many different means of doing the same thing. This flexibility has given developers a lot of options and great power in structuring their apps. However, the downside is that often we are left wondering which way is the “right way.” Left to our own devices, poorly structured apps can risk becoming scope soup.

Ruby on Rails encouraged “convention over configuration”–let the experts decide sensible defaults to save you from the decision fatigue of configuration. I’ve always liked that philosophy because it’s allowed me to focus more on business logic and less on implementation details.

Fortunately, Angular 2 appears to have taken a step in the direction of structure with components. Angular 1 was recently upgraded from 1.4 to 1.5, which also introduced support for components. It is claimed to be a much simpler way to architect front-end applications.

Angular components remove many of the time-consuming decisions in building apps. For example, you no longer have to choose between an ng-controller or directive: you can simply use a component along with Angular’s sensible default settings.

Why We Started Using Angular Components

I’d been working on some large Angular 1.4 apps for a while. The more I worked on them, the more I thought, “There’s got to be a better way!” Our directives were tightly coupled with our data services. The data flow was unstructured and difficult to wrap my head around. And it was generally hard to track what was going on.

Without conventions, it’s easy for teams, developers, and projects to go down the wrong path. Seeking new methods for clarity and standardization, I looked into React and Redux. The concept of one-way data flow seemed like a promising solution for many problems. But ultimately, switching to a new framework wasn’t an option for the projects I was currently working on. My search for a cohesive framework continued.

Around that time, the Fresh team attended an Angular 2 meetup where Jeremy Foster spoke about Angular 2, the concept of data flowing down and actions flowing up, smart versus dumb components, and using input and output bindings for your components. By the end I was excited to jump into Angular 2, but it still wasn’t a fit for our current projects, mainly because it is still in beta.

Shortly after, Angular 1.5 was released with component support. The timing was perfect. This was the ideal middle ground: we could leverage the bleeding edge component and component router in our Angular 1 apps. And we didn’t have to transition to Angular 2 Beta right away. We started using Angular 1.5 components in a new project and have discovered that its features, like a simple data flow and new component router, leave less of a margin for error and produce cleaner code than AngularJS 1.4.

Simple Data Flow

Angular components input and output bindings for simple data flow

Components have input and output bindings. Inputs should use one-way data binding “<“. Outputs should use output bindings “&”. This is encourages one-way data flow where data flows down and actions bubble up.

Smart components are responsible for calling data services, as well as performing standard CRUD actions on your data.

Dumb components are responsible for receiving data from smart components, rendering the ui, and reacting to events and sending actions to smart components.

This simplified data flow helps developers structure components in a way that’s easy to understand. Each component has access only to its own data and view. There are no longer inherited scopes like before; the scope is always isolated for a component, decreasing confusion about where the data is changed.

New Component Router

The component router is another new feature in Angular 1.5. The component router loads components into the ng-outlet. If you’ve ever used ui-router, ng-outlet works similarly to ui-view. The primary difference is that it loads in a component instead of a controller and template.

The component router supports non-terminating routes. In other words, it can support nested subroutes, which is useful when you need to route URL subpaths.

Conclusion

Components in Angular 1 are a solid way to build your Angular app, and they may help you achieve a clearer app structure in comparison with other means of organization. Components also promote loose coupling and single responsibility. You will be in good shape as long as you follow the conventions in the Angular developer guides for components and component router. And if used correctly, AngularJS components can also promote developer sanity.

Travis Luong

Travis Luong

You might also like...

30

Jan.

Marc Wallace

Machine Learning UI Starts with Trust

With the increasing amount of data, the ability to detect patterns and surface them in a trustworthy and actionable manner is key to remaining competitive. Let’s start by defining a couple things first: UI (User Interface) is the means by which the user and a computer system interact. For the purpose of this article we … Continued

28

Jan.

Jeff Alexander

The Value of Robot-Centered Design

Designers, developers, and engineers have spent vast amounts of time and effort understanding how humans interact with technology. Human-Centered Design The study of human factors guides our knowledge of how our behaviors, beliefs, education level, and past experiences influence how we accept and work with digital tools. Those who create computers, mobile devices, software, hardware, … Continued

21

Jan.

Jeff Dance

Creating High-End Applications by Blending Functionality and Emotion

Application design should focus on creating an experience that users remember. The key question to ask is why they will remember it. Is it emotion that invests your users? Or does functionality play a significant role as well? Functionality should always be placed front and center: It ensures that your application works. But that’s not … Continued