Apr 10 2018

Angular dependency injection: why?

Published under Technology

At work we teach and consult on various topics, notably (for this post) Angular. We are often asked why Angular has and heavily uses dependency injection. Here are my answers to this question; I haven’t had a chance to compare notes with the rest of our Angular expert team, so here it is, on my personal blog. (However, special thanks to Paul Spears, who helped clarify these ideas.)

Dependency injection has a considerable complexity cost, so it’s important to have good reasons to add this complexity to a framework or application. There are an unlimited number of potential features and patterns to follow, so the default for any particular feature or pattern must be “no”. Moreover, popular Angular alternatives (like React) thrive without a dependency injection system, constituting an “existence proof” that it is not a necessity, but rather a choice.

There are a variety of potential reasons to say “yes” to DI, categorized here.

General software engineering reasons

Dependency injection far predates Angular, and is in common use among the (fast, long-term) community of Java Spring developers (among many others). Discussion and reasoning around dependency injection (and related concept, Inversion of Control) are widely available, here are a few starting points.




Angular team reasons

Angular provides access to various capabilities via dependency injection. If you code needs access any of these things, it get access via the dependency injection mechanism. In other words, the Angular team has chosen to use dependency injection therefore your application must use dependency injection. Of course this is something of a tautology. The underlying question is: but why did they do it this way?

To answer that, the Angular team has supplied an explanation of the DI pattern and why they think it is a good idea. Rather than repeat all that here, their reasons are worth a read, and overlap what I have written below.

Polymorphism for testing

Angular developers often talks in terms of services; injecting services, using services, coding services. Although there are additional meanings to the word service beyond the word class, service is often used as a synonym for class, or even as a synonym for “file with some code in it” among the Angular community.

It is common for a unit (or integration, or even E2E) test to need a different implementation of a class, then that which is used during normal operation. DI provides a convenient and flexible way to provide such alternative testing implementations.

Of course, the React community gets by without this, and still is able to perform testing. Typically this is done by treating the JavaScript module system (CommonJS “require”, or the newer “import”) as if it were a configurable DI system, with special machinery to override the meaning of an import during testing. Conveniently, this is done without any syntactical or semantic overhead during normal non-testing operation – a fairly compelling feature. Still, DI provides additional flexibility, configurability, and a more explicit means of achieving polymorphism for testing.

Polymorphism for environments

Sometimes an application needs a different implementation of the same interface (or “service”) depending on the environment in which it is deployed. Dependency injection handles this nicely and explicitly. For example:

  • An application might be compiled for both web use and Electron use, with certain service implementations swapped out.
  • An application might be hosted locally versus in the cloud service, and use a different data backend implementation (of the same Angular service interface presented to the UI).
  • An application compiled for Universal (server-side rendering) use, commonly needs certain bits swapped out during server compilation/execution.

Transitive injection

Code which itself relies on a service available via dependency injection (for example, HTTP) will need to be injected so that it can receive its own injectables.

Instance control

Without a dependency injection system, it is still straightforward to implement either a set of functions (that is, not a class at all, no state), or a singleton class instance, or a class instantiated for each use. But the Angular dependency injection system can achieve much more sophisticated instance control. For example, by configuring providers, a service could be shared by portions of a component tree, but not by the entire application. This sort of clever DI configuration can replace extensive discussion and code with just a couple of lines of configuration.

Reminder: don’t always use services

As we teach classes, and discuss code “in the wild”, developers innocently ask:

“I have some code that doesn’t go in a component, where do I put it?”

Unfortunately, when this question comes up in a Angular context, the obvious answer is usually “put it in an Angular service”. This answer is convenient, especially for teaching how to use Angular features. Unfortunately, this answer is also a lousy default.

The default answer of where to put code should be: in a source code file, in a function or class etc., which are not in any particular way connected to a web application framework by Angular. Only move the code to a Angular-related construct when the need to do so comes up. In a mature, complex application you may find that a sizable portion of the overall code lives outside any Angular construct, outside a Component or Service or NgModule, simply sitting as TypeScript code in source files.

Code should be moved from an ordinary source code file to a Angular service only to meet these needs:

  1. The code relies on some other service that will be injected to it (for example HTTP).
  2. The code will be swapped out for testing.
  3. The code will be swapped out for different environments.
  4. The code has state, in the instance of that state should be tied to the lifecycle of a Angular construct (module, component, etc.).
  5. The code is example code, for the purpose of teaching how Angular service or DI works.


Comments Off on Angular dependency injection: why?

Dec 10 2017

Filling up your issue tracker – at scale

Published under Business,Technology

Sometimes when working on a project at work, we find out about a pile of features or changes needed. This can happen at the beginning of a project, at the start of the major initiative, after deploying a project (which triggers much user feedback), etc. Sometimes we have so much to absorb and divvy up into issue tracker items, that the logistics of doing so are painful.

Just thinking through and writing down 50-100 issues (or more!) is too tedious for one person to get through quickly. To divide up this work (of describing a bunch of issues in enough depth someone could work on them), I’ve come up with the following approach.

First, I jot down a list of all the areas of the system where there are new issues to enter. This forms an outline of areas that have issues, I don’t even attempt to make an entry for every likely issue.

Second, I record one or more videos, showing the screen of the system I want to add issues for, alternating back and forth with code. As I go, I describe each problem/opportunity/fix, that should become an issue. Depending on whether the new issues are closely related to existing ones, sometimes this includes bringing up the issue tracker (Jira, etc) also, talking through existing items about work remaining on them.  Sometimes something that first seems like a new issue, is really just a refinement of the success criteria of an already known issue.

Having spent potentially quite a while just describing issues (there have been times when this goes on for over an hour), I hand over the recording(s) to a relatively new person on the team, who will go through and translate this rapid-fire description into a set of items. Typically it’s fastest for the person to do that not by directly entering the items, but by just typing the candidate issues into a document. (If the list is big enough, it can pay off to have a transcriber handle the first pass – turn the words from the video/audio, into text.)

Finally, that initial rough list of candidate issue, goes to the project leader(s) of the project in question, to clean up, refine, review, approve. Then someone copies the approved text into the issue tracker.

Admittedly this is not a complex process, hardly worthy of a blog post. But someone once asked me how we successfully enter so much detail into so many items on complex projects – and here is the answer. Entering all that really does pay off. It is much more plausible to delegate work if you have described it as thoroughly as you can.

Comments Off on Filling up your issue tracker – at scale

Nov 16 2017

Adjust base href via a NPM package.json scripts

Published under Technology

Suppose you wanted to adjust the base HREF in an index.html file using a regular expression, as part of a build process you are cobbling together using NPM scripts. How could you do that? Here’s one answer, though this only works if the sed command line tool is available (as it will be almost always on Linux or Mac, and only if you install it on Windows):

Unfortunately, I have begged a question. (In the traditional sense and that I assumed an answer to a question, not the modern repurposed thing of the phrase). Is it actually a good idea to use the combination of a regular expression and a script written in a JSON file, to do anything at all?

Looking at the multiple levels of \\/\/\/\\\///\// escaping above, I think the answer to this question is clearly no. It would be better to use some other means for this adjustment. On other projects we have done the same manipulation using a tool that manipulates the HTML structure. It is more verbose but vastly easier to understand.

(Incidentally, I used to do things somewhat like the above to adjust the base URLs for Angular applications.   This is not necessary anymore if using Angular CLI  – it has an option built in, –base-href.)



Comments Off on Adjust base href via a NPM package.json scripts

Sep 13 2017

TypeScript as ES2015/ES2016+ compiler

Published under Technology

I frequently encounter packages on NPM which bring in Babel to compile ES2015/2016+ down to older JavaScript suitable for a wider range of browsers. Babel is a very effective tool for this, it has been around quite a long time, and is highly configurable and flexible in future ready. It has an amazing community and reputation.

But – it is also surprisingly “heavy” in its impact on your tools installation. A typical Babel installation with a typical set of plug-ins can easily bring in 20,000 or more files, spread over hundreds of transitive dependency packages. On a huge project this might not be noticed, but on a small or medium project it can easily be the largest dependency.

Are large NPM dependency trees a problem? Theoretically no, but practically they have some downsides. Dependencies bring risk, and lots of dependencies inevitably bring more risk. If you depend transitively on hundreds more packages, your project is more vulnerable to the sort of NPM vagaries that happen from time to time (the most famous being left-pad), your project is more inclined to fall behind current versions, and most annoyingly in corporate settings, that long list of plugins and transitive dependencies is more likely to cause heartburn among lawyers who evaluate licenses.

There is an easy way to ease this problem, but it involves a minor update to one’s thinkinh. Find the spot in your mind where you may think:

“the TypeScript compiler is a tool for compiling TypeScript code to JavaScript and type checking it”.

The actual truth in 2017 is:

The TypeScript compiler is an excellent, well supported, frequently-updated general-purpose tool very suitable for non-TypeScript users. It does a great job compiling a broad array of standards-path ES2015/16/+ features down to ES2015 or ES5. It fits in well with overall project build tooling. It is completely suitable to use the TypeScript compiler on a non-TypeScript project for this purpose.

The TypeScript compiler has several substantial practical benefits over Babel:

  • It is a single dependency with no transitive dependencies.
  • Usually faster compilation.
  • It is developed by a team at Microsoft, who do a great job grinding away at the boring aspects of this work, shipping a long series of updates which keep fixing bugs and adding features.
  • It installs quickly and has far fewer failure modes in installation (because of no transitive dependencies).
  • Just one open source license to review (no transitive dependencies)… from a company that your company probably already buys a lot of stuff from anyway.
  • Just one version to update, and one configuration file to tweak which features you are using.
  • WebPack and other plug-ins available, quite analogous to Babel.

As of 2017, my recommendation is to consider TypeScript as the default solution for compiling ES2015/16+ code in non-TypeScript projects, and use Babel as a fallback if your project needs cutting-edge features that are (intentionally) not yet in TypeScript.

Comments Off on TypeScript as ES2015/ES2016+ compiler

Jul 02 2017

Cycle JS – example application and video tour

Published under Technology

I recently learned a lot about CycleJS, which had been recommended to me in the category “you probably won’t use this for your day job right now, but you will learn a lot by looking”. And indeed, it has turned out to be the case. Cycle can be thought of as an answer to the question “what if we only had Observables and virtual DOM ? Would that be enough to build applications?” It appears to me that the answer is yes, though the tooling is not really all that complete yet.

Along the way I wrote a small example application and recorded a series of short videos (below) explaining some of the things I learned along the way, how to use various Cycle features, and especially about interesting points of comparison between Cycle and Angular and React.

These videos are not an introduction to Cycle, nor do they replace the documentation. Rather the idea is to give a flavor of how things work in Cycle from an application developer point of view, compare and contrast with other approaches, and point out why some of the ideas are quite valuable even if initially not obvious.

As I write this, have recorded four videos and made it about 70% of the way through the example application, talking through how it works and why. Questions and suggestions are much appreciated, probably the best place to put those is in the issue tracker of the example application linked above.





Comments Off on Cycle JS – example application and video tour

Jun 18 2017


Published under Technology

Much of my work (as a technology guru at Oasis Digital) is around the intersection of the most current technology (such as Angular) with existing complex, valuable systems used by our customers. Recently an opportunity came up in which we may interact with some older software written in Smalltalk. I’ve used Smalltalk a bit some years ago, but many of the others at work have not.

To help our team understand a bit about Smalltalk, I demonstrated some of the basics (with Pharo, a surprisingly nice open source implementation) and spoke a while. At the end, someone pointed out that many of the words and the slides might be useful as a blog post for future reference.

What is Smalltalk?


  • Advanced technology – from an earlier era
  • http://worrydream.com/EarlyHistoryOfSmalltalk/
  • Smalltalk-76, -80
  • Byte magazine Smalltalk issue – see PDF available online; this issue seemed like sheer magic when I stumbled across it (already worn and tattered) in a library in the mid-1980s.
  • In some ways Smalltalk was decades ahead of its time
  • Descendant of “the mother of all demos”
  • Predecessor of much of what we use today
  • Alan Kay, 1971, “The best way to predict the future is to invent it.”

The basics

  • One of the first OO languages
  • (very) dynamically typed
  • Everything is an object
  • Syntax quite different from most of what we use today
  • Runs on a virtual machine (like JS, Java, .NET, etc.)
  • Contains many ideas that set underneath much of what we do
  • Environment consists of many live objects, developer can manipulate
  • Those live objects reside in an “image”, which can be persisted, shared, deployed




  • https://squeak.js.org/
  • Free, open source
  • not what you might guess!
  • Smalltalk VM, run in a browser
  • Not very practical, too many layers of VM


  • http://pharo.org/
  • Free, open source
  • Fork of Squeak
  • Generally newer, more polished look
  • Old things cleaned up
  • As far as I can tell, still using the same VM as Squeak, Cog VM
  • Non-native UI, looks quite nice


Connecting to the world

Source control

  • You don’t write Smalltalk as a pile of files
  • Instead, manipulate classes etc, inside an image
  • Tooling adapts this to a file structure…
  • … when you then can put in source control for collaboration
  • The result is a repository with numerous small files, which maps to and from native Smalltalk code
  • Monticello – let’s look at it.
  • Future thing – Iceberg – use this to understand the image-to-file mapping. https://github.com/pharo-vcs/iceberg


Smalltalk runs in an image, but many/all implementations also provide all the primitives you need to talk to files.


Many/all implementations also provide all the primitives you need to talk to networks, plenty of protocols, etc.

(server-side) web apps

(single-page) web apps

  • Nothing that I know of, to write these in Smalltalk
  • … but an Angular or other modern web UI could sit on a Smalltalk server


There are:

  • Drivers for SQL databases
  • Drivers for NoSQL databases
  • Object databases written in Smalltalk

Human factors


There is one. I’m not in it. Who uses Smalltalk today?

Learning more

Comments Off on Smalltalk

Older Entries »