As with many of my articles, instead of learning a process from scratch, I’ve decided to interview industry experts. That way you, as the reader, get to hear directly from these experts and learn their strategies. With that in mind I reached out for help and was contacted by John Donley, a Software Engineer at Charge, a San Francisco software company. Here’s what he had to say:
Separate Your Data Services from Your Controllers
It’s good to keep your data services separate from your view controllers because it allows you to keep view state logic away from your business logic.
A data service is anything that talks to an external API. At Charge, we have a data service that fetches the user’s list of devices. The device data service is responsible for keeping track of the list of devices and where to post to create a new device.
With all of the HTTP work happening one layer removed from the controller, the controller is freed up to focus on representing the state of the data to the user. Which makes your controllers smaller and more readable. It also has the benefit of making your controllers easier to test. Mocking an entire HTTP response takes a lot more time than mocking a list of objects or an error.
Split Unauthenticated and Authenticated Things into Separate “Apps”
When we started out, we had an app that would let users log in or create an account in order to manage their Charge service. We had a bunch of code that tried to determine whether the user was logged in, and what to do if they were or weren’t.
We saved a lot of headaches and prevented security slip-ups by splitting the app into two separate angular apps within the same project. The auth app handles creating accounts, and authenticating users. Which frees up the main app do its job the same way every time, starting with retrieving the user’s account information.
Use Modules for Things That Are Shared Across Projects
Here at Charge we like Angular so much we’ve used it for all of our web apps. So of course we found things we developed in-house for one project that we then needed in another.
We’ve used Angular’s flexible module structure to allow sharing of common code between projects. For example, we have a bit of code to determine whether the app is running in a development environment or in production. That code code lives in its own module so that any of our projects can include it.
Put Outside Libraries into Constants
Angular is all about dependency injection, which is great for all kinds of reasons. One reason is all dependencies for a given controller/factory/service are listed right in the definition of the object. Anyone reading your code will know where to find the things that code depends on.
Outside libraries usually get loaded into global variables, which means they are available everywhere. But using a global variable makes dependency injection impossible, since otherwise-isolated code now requires knowledge of the entire application and its context to use the outside library. If you add an Angular constant for each external library, you can then inject them like all the ‘internal’ parts of your application rather than relying on outside global variables.
Angular’s Built-in Functions Are Your Friends
Angular has some great built-in functions that live right on the `angular` object, like extend(), copy(), and forEach(). Extend allows you to merge one object onto another without losing a reference to the first, which is the cause of many tricky UI-binding bugs. Copy replaces one object entirely with a new one. And forEach makes iterating over objects and lists much simpler.
The API reference describes all of these functions and more in great detail in the ‘function’ section.
Don’t use Angular 2.0 (yet)
It’s still too early. Even the Angular developers think it shouldn’t be used in production. If you’re just getting started on a prototype or want to play around with the latest and greatest, then give it a whirl. For anything real, stick to Angular 1.
Ed note: In a conversation with Andrew, he said the new platform doesn’t have much resemblance to Angular 1, except in name. Essentially, they ripped the guts out of version 1 to make the new program, which is considerably different from version 1.
For More Information
Contact John Donley, a Software Engineer at Charge, a San Francisco software company.
