Advantages of Creating a Custom Shared Library in Angular

The DRY Principle

Software is complicated. It has a lot it must do: connecting to databases, reading and writing data, following all the rules of a business, and displaying an interface to the user that is not only functional but also intuitive, empowering, and styled to brand guidelines.

With that much to do, one thing becomes very important: staying organized.

This has been the subject of many a blog post already, as well as quite a few books and plenty of college courses. Programming paradigms are built around organizational methods. From MVC to ReactiveX, these methodologies help programmers keep their code organized.

A fundamental goal of that organization – and one of the earliest lessons programmers are taught – is the DRY principle: Don’t Repeat Yourself.

Why, though? Computers are fast, and storage is cheap. So what if we’ve got some repetitive code? There are a few solid benefits to staying DRY:

• Less code takes less time to write. That means more time for the programmers to catch and fix bugs, polish the interface, and develop new features.
• Less code is easier to maintain. If you need to change the way something works, it’s far more efficient to do so in one place than in 10.
• Less code means fewer bugs. By keeping the code to do something in one place, fixing a bug once means it’s fixed everywhere.

Recently, Buildable has made a big improvement in keeping our code DRY.  

All the software we build has some common components, like “section header,” “list of data,” or “editable form.” Over time, we’ve built some powerful functionalities into these components – searching, sorting, and filtering lists of data, for example.

In each project, these components were following the DRY principle: The code was written in one place and reused across the project.

Outside each project, however, we weren’t staying so DRY. Each project had its own version of these common components. Features and functionalities migrated from project to project as needed, but this was done manually with an engineer copying over (or recreating) the code on demand.

Our development process is now much simpler thanks to our custom shared library. Every feature is available to every project immediately – no manual synchronization required.

We’ve called this library the Buildable Foundation.

Building the Buildable Foundation

The Buildable Foundation only contains frontend components. (But we'll let you in on a behind-the-scenes secret: We are working on a similar project for shared backend components, too. Stay tuned!) Our frontend development is centered around Google's Angular framework. 

What is Angular?

Angular is a web application framework, similar to Apple's UIKit for iOS, or Microsoft's Windows Presentation Foundation. Originally created by Google, Angular is an open-source framework for the web; it provides tools to structure, build, and test applications.

As it turns out, converting a collection of Angular components into an Angular library isn’t too difficult. Angular has a few tools available to help you get started, and since we had already built the components, moving them over was easy.

However, those tools only went so far as being a separate library within a single project. In practice, there was almost no difference between this approach and the way we’d originally been managing the code. The next step was to break out the library and make it available to other projects.

Now, there are also some tools for doing this, but they make some assumptions about the workflow involved, which in our case ranged from “mildly incorrect” to “seriously wrong.” Fortunately, there are other ways, but the setup is fairly involved.

Our first take on sharing the library between projects built on some tools we were already using. We manage all of our code using GitLab, and Node Package Manager (NPM), the tool that manages the frontend libraries in our projects, has built-in support for using a Git repository instead of an NPM repository. (It even supports version numbering by way of Git tags!)

Unfortunately, NPM only works with a Git repository in a very specific format. That format, while available as the output of an Angular library, is tucked away somewhere that NPM can’t (or rather, won’t) find. For testing purposes, we were able to work around this – by creating a second Git repository and using a little-known feature of Git to copy over just the files we wanted – but the resulting workflow was slow, somewhat fragile, and annoying; an improvement, but marginal at best.

From there, we decided to go heavy-duty: a Docker container running Nexus Repository Manager. It’s a purpose-built tool for replacing the public NPM repository. By changing the configuration of our projects, and uploading the Buildable Foundation into our repository, we can use it in our projects as if it were a public library.

After a bit of configuration on GitLab, we have made the development process for the library much easier. Our developers can check out the Buildable Foundation’s source code, make changes, and submit their work for review. If the updates earn approval from the rest of the team, they are then merged in. GitLab works with Nexus to make the updated version available to all projects using the Buildable Foundation. Those updates are then integrated into all of our projects, automatically.

Built For You

The end result is incredible: While each project’s frontend remains just as customizable as ever, the powerful functionality and logic backing those tools are now consistent across all projects. Remember DRY (Don't Repeat Yourself)? Whether it’s a new feature, performance improvement, or bug fix, we write the code for one project, and the DRY benefits go to all of them. 

In other words, as our developers improve bits and pieces of our software projects over time and for other customers, we will share those updates with your project, too. When we add new accessibility features to our forms or add hyper-useful functionality to our filter system — like scheduled reporting shared across teams — you can bet on seeing it in your system soon after.