10 Lessons Learned in Enterprise Angular Development

AngularInDepth is moving away from Medium. More recent articles are hosted on the new platform inDepth.dev. Thanks for being part of indepth movement!

This blog post is a follow up to the podcast I recently did with Adventures in Angular.

Before I begin I wanted to provide some context to where these lessons are coming from. I am a Web Architect at Hyland Software located in a suburb of Cleveland, Ohio. Over the last two years I’ve been assisting other teams within the organization to modernize existing WPF and ASP.net Web Forms based applications to Angular. So far I’ve interacted with around 50 developers ranging from previous web experience, to developers that have mastered C++ and this is a whole new world. Reflecting back on those two years, below are the top lessons learned.

1 Seasoned Web Developers will make bonehead mistakes

This one I learned from Ed Morales, a developer at Teradata. Developers that have been developing on the web have learned patterns and outdated ways of doing things. When you introduce Angular to these developers, they sometimes keep those old habits and don’t do it the “Angular way”. For example, one team I was working with was using document.location to perform navigation within their application, instead of using routerLink.

Treat everyone as a newbie.

2 Utilize “View” components

In your project source root create a folder called views. Views are smart components that are routed. Instead of the component file suffix use view. This will help keep your project organized because now, at a glance, you can see the general structure of the application, and can use your URLs to help determine where the code is located.

3 Bubble your components up

Component should start their life as children to view component. As the application begins to grow and a second view requires this component, migrate this component into a shared folder. When a second application requires this component, bubble this component a second level up into a library.

4 Avoid premature separation

Don’t put components in a library (shared via npm) if there’s only one application consuming it. Hopefully a majority of readers are thinking “obviously”, but you would be surprised. The gut reaction to many teams starting up is to organize their components in two buckets. Ones that the application will use, and ones that have potential reuse. Even if you know at some point in the future there will be another application, hold off on the urge to separate until you actually need to.

Personally, I think premature separation occurs because web developers recall nightmares of untangling spaghetti HTML/JavaScript for reuse. Angular’s modular approach allows us to easily take code from one solution to another with little effort.

5 Teams should develop a “fun” application

Too often I see teams just ramping up decide to do Tour of Heroes in parallel their actual project. It just doesn’t work. Instead, have the team do individual learning paired with a daily meetup on one of the topics found under the fundamentals or techniques sections from Angular.io. Combine this with building an application that with as a team with the expectation of throwing it all away. Only commit to one or two weeks for this exercise. This gives the team a chance to figure out their strengths, take a first pass at organizing their project, and ironing out the basic development workflow.

6 Break out of the Research Loop

Don’t get caught up in doing too much research and never actually ship anything. After building your prototype warm up, go head first into developing your product. Be agile and start with something and get feedback on it from stakeholders. You don’t need to know everything up front.

7 Decide on a state management strategy and use it across the organization

Multiple teams each choosing their own client side state store pattern (ngrx, ngxs) is a recipe for disaster. Try to align the teams on one pattern early on. Doing this early will preserve the components’ portability amongst teams.

8 Shareable Components

There seems to be a holy grail at a lot of organizations, including mine, to build shareable components. The purpose being to reuse each of these components within different applications. If you’re sharing smaller components like buttons, and list controls the design is typically straightforward. As these components usually have a single responsibility and it’s easy to isolate their behavior. However, as component complexity increases, it’s shareability decreases. Consider using content projection instead of a collection of configuration parameters.

Depending on the size of the organization, create a component governance group to provide guidance on shareability and best practices.

9 Resist Building Helper/Utility Libraries

It may be tempting to create libraries and helpers early on to wrap common functionality. Resist this temptation especially if you’re building a component library. This is has two negative impacts. First, the teams ramping up will not only have to learn Angular and other external libraries, but your own custom wrappers. Secondly, teams will be referencing your code by example, if they are unable to reuse code you’ve written within their own code base they will stop referencing it and begin to create their own patterns.

10 Train to embrace the community (last but not least)

Five years ago, being a part of the community was optional. Enterprise Developers working on the Microsoft stack could comfortably get their job done by reading a book or two and putting that knowledge into practice.

Too often I receive an internal developer question about Angular, and the answer is a Google search away from them. We need to retrain our employees on how to lookup bugs on Github, scan code bases, engage with other developers on Gitter and StackOverflow, read blog posts, and listen to podcasts. The way software is developed has changed, and so should our learning practices.

The best developers are the most knowledgeable because they have engaged the community.

Have a lesson I missed? Need assistance or advice on undertaking your own modernization effort? Reach out to me on Twitter @cgatian or comment below.