Unit testing Angular 1.5 components – a detailed guide [“NG 1.5 from the trenches” 6/7]

This post is the 6th part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

Components are the most tricky part of Angular 1.5 when it comes to testing. They are bound to HTML templates and DOM events, they have “automagically” instantiated attribute bindings, and they are composed into a tightly coupled component tree, without an obvious way to isolate parent and child components.

There are many possible approaches to testing components, but the one we’ve developed in our project works well for us and has proven itself during over 6 months with a big app, so I’d like to share it.

Continue reading “Unit testing Angular 1.5 components – a detailed guide [“NG 1.5 from the trenches” 6/7]”

Writing Angular 1.5 project in ES6/ES2015 [“NG 1.5 from the trenches” 5/7]

This post is the 5th part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

As you could notice if you read the previous posts in this series, we use ES6 in our project. It changes the way you write Angular 1.5 components (and other constructs like services or tests), so in this post, I’ll briefly discuss how the main NG 1.5 elements look like in ES6.

Continue reading “Writing Angular 1.5 project in ES6/ES2015 [“NG 1.5 from the trenches” 5/7]”

A flexible Angular 1.5 project structure (the “fractal” architecture) [“NG 1.5 from the trenches” 4/7]

This post is the 4th part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

In the previous two articles, I’ve described the conceptual structure of an Angular 1.5 app: how to split an app into components and how components communicate. Now is the time to discuss the physical organization of a component-oriented app: the directory and file structure.

Continue reading “A flexible Angular 1.5 project structure (the “fractal” architecture) [“NG 1.5 from the trenches” 4/7]”

Communication between Angular 1.5 components (and with the API) [“NG 1.5 from the trenches” 3/7]

This post is the 3rd part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

Components must collaborate to provide complex business behavior

In the previous post in the series I’ve discussed the “static” part of the component-oriented Angular 1.5 architecture: the anatomy of a component and how the app can be structured as a component tree. I also mentioned that we use a lot of small, focused components. What I haven’t discussed yet is how all these components communicate (pass data and propagate user actions and state changes). This will be the topic of this post.

Continue reading “Communication between Angular 1.5 components (and with the API) [“NG 1.5 from the trenches” 3/7]”

Angular 1.5 app as a tree of components [“NG 1.5 from the trenches” 2/7]

This post is the 2nd part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

  • Starting a new app in Angular 1.5 – does it make sense?
  • Angular 1.5 app as a tree of components [THIS POST]
  • Communication between Angular 1.5 components (and with the API) [COMING SOON]
  • A flexible Angular 1.5 project structure (the “fractal” architecture) [COMING SOON]
  • Writing Angular 1.5 project in ES6/ES2015 [COMING SOON]
  • Unit testing Angular 1.5 components – a detailed guide [COMING SOON]
  • E2E testing of component-oriented Angular 1.5 app [COMING SOON]

A new way to write Angular 1 apps.

A seemingly cosmetic addition introduced in NG 1.5, the module.component() method, can have a big impact on your app. It enables you to architect your whole app as one big tree of components, and to completely get rid of controllers (remember the [in]famous Angular 2 “RIP” talk?). Although NG 1.5 doesn’t force it upon you like NG 2, it makes it possible if you want.

It was already possible to achieve a similar effect in NG 1.4, through the combination of directives, isolated scope, and controllerAs option. It was complicated, though, and caused a lot of friction, so people usually did it on a much smaller scale, only for a couple of selected components. NG 1.5 changes the game. The module.component() method makes this so easy, that it feels natural to make components even for the smallest, dumbest parts of the UI.

We went in this direction as far as possible with our app and are very fond of such component-oriented architecture. In this post, I’ll show how it looks like.

Continue reading “Angular 1.5 app as a tree of components [“NG 1.5 from the trenches” 2/7]”

Starting a new app in Angular 1.5 – does it make sense? [“NG 1.5 from the trenches” 1/7]

This post is the 1st part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
The module.component() method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.

Table of Contents:

  • Starting a new app in Angular 1.5 – does it make sense? [THIS POST]
  • Angular 1.5 app as a tree of components [COMING SOON]
  • Communication between Angular 1.5 components (and with the API) [COMING SOON]
  • A flexible Angular 1.5 project structure (the “fractal” architecture) [COMING SOON]
  • Writing Angular 1.5 project in ES6/ES2015 [COMING SOON]
  • Unit testing Angular 1.5 components – a detailed guide [COMING SOON]
  • E2E testing of component-oriented Angular 1.5 app [COMING SOON]

The context

At the beginning of the year (mid-January) we were starting a brand new, greenfield project. We faced an important decision: in which version of Angular should we build it?

With the Angular 2 beta just released, and the Internet all the rave about “now being finally the right time” to consider building production apps in NG 2, it was surely a tempting option. On the other hand, with Angular 1.5 release candidate available (and the final 1.5.0 version lurking just around the corner) it seemed an interesting alternative.

We were torn between two choices:

  • Should we “future-proof” ourselves, but endure all the pains of Angular 2 infancy?
  • Or should we stick to the mature 1.5 version, but cope with the migration to NG 2 in the future?

Continue reading “Starting a new app in Angular 1.5 – does it make sense? [“NG 1.5 from the trenches” 1/7]”

How to stop labeling people: 6 ways to prevent the Fundamental Attribution Error

We’re quick to label people. One a bit too harsh review of your code, and you’ll see the reviewer as narrow-minded and ill-willed from now on. One unfortunate comment on a meeting and you’ll consider your colleague as adversarial and non-collaborative for years. One poorly written requirement and you’ll think of a stakeholder as inherently careless or stupid.

Such labels are hard to erase and lead to a poisonous atmosphere. But does it have to be this way? Why do we form these negative opinions? And, more important, how to avoid it?

Continue reading “How to stop labeling people: 6 ways to prevent the Fundamental Attribution Error”

Can we do Scrum without meetings?

Developers hate meetings. They seem such a time-waster. But there are a lot of meetings in Scrum. Way too many for some people’s taste.

Completely dropping Scrum ceremonies is out of the question. They are the main sources of communication and feedback that enable empiricism – the main advantage of Agile. But do we really need meetings for these ceremonies? Can’t we get the feedback continuously?

  • Do we have to run daily scrums? We sit together in the same room. We can coordinate throughout the whole day, as needed, not only once a day in the morning.
  • Why review our work with stakeholders only once a sprint, in a big batch? They’re sitting at the same office. We can make a review feature by feature, just as they are completed.
  • Wouldn’t it be better to discuss improvement ideas immediately when one comes up, instead of waiting till the end of a sprint to make a formal meeting out of it?
  • We’re doing continuous integration. Why do we need sprints at all? What’s the benefit of arbitrarily timeboxing our work?

I hear a lot of arguments in this vein. And they sound reasonable. Isn’t Agile, after all, about getting feedback as frequently as possible? Isn’t it in the spirit of XP to amplify good practices to the max? Why, then, Scrum ceremonies are so rigidly scheduled? Is it possible to break free from the tyranny of meetings? What are the risks?

Continue reading “Can we do Scrum without meetings?”