Looking for

Sunday, June 25, 2017

In the previous post "Dirty secrets on dependency injection and Angular - part 1", you've explored how DI at component level, can produce different instances of a service. Then you've experienced DI at module level. Once a service is declared using one token in the AppModule, the same instance is shared across all the modules and components of the app.

In this article, let's revisit DI in the context of lazy-loading modules. You'll see the feature modules dynamically loaded have a different behaviour.

Let's get started...

Tour of hero app

Let's reuse the tour of heroes app that you should be familiar with from our previous post.
All source code could be find on github.

As a reminder, in our Tour of heroes, the app displays a Dashboard page and a Heroes page. We've added a RecentHeroCompoent that displays the recently selected heroes in both pages. This component uses the ContextService to store the recently added heroes.

In the previous blog, you've worked your way to refactor the app and introduced a SharedModule that contains RecentHeroCompoent and use the ContextService. Let's refactor the app to break it into more feature modules:

DashboardModule to contain the HeroSearchComponent and HeroDetailComponent

In [1] you import SharedModule which defines common components like SpinnerComponent, RecentHeroesComponent.
Note in [2] that HeroService is defined as provider in both modules. It could be a candidate to be provided by SharedModule. This service is stateless however. Having multiple instances won't bother us as much as a stateful service.

In [1], the declarations section is really lean as most components are declared either in the features module or in the shared module.

In [2], you now import the SharedModule form AppModule. SharedModule is also imported in the feature modules. From our previous post we know, in statically loaded module the last declared token for a shared service wins. There is eventually only one instance defined. Is it the same for lazy-loading?

In [3] we defined the module for lazy loading, more in next section.

In [4], providers section is lean similar to declarations as most providers are defined at module level.

Running the app, you can observe the same syndrom as when we define ContextService at component level: DashboardModule has a different instance of ContextService than HeroesModule. This is easily observable with 2 different lists of recently added heroes.

Angular adds @NgModule.providers to the application root injector, unless the module is lazy loaded. For a lazy-loaded module, Angular creates a child injector and adds the module's providers to the child injector.

Why doesn't Angular add lazy-loaded providers to the app root injector as it does for eagerly loaded modules?
The answer is grounded in a fundamental characteristic of the Angular dependency-injection system. An injector can add providers until it's first used. Once an injector starts creating and delivering services, its provider list is frozen; no new providers are allowed.

What about if you what a singleton shared across all your app for ContextService? There is a way...

In [1] remove ContextService as a providers. Define in [2] a forRoot method (the naming is an broadly accepted convention) that
returns a ModuleWithProviders interface. This interface define a Module with a given list of providers. SharedModule will reuse defined ContextService provider defined at AppModule level.

Where to go from there

In this blog post you've seen how providers on lazy-loaded modules behaves differently that in an app with eagerly loaded modules.

Dynamic routing brings its lot of complexity and can introduce difficult-to-track bugs in your app. Specially if you refactor from statically loaded modules to lazy loaded ones. Watch out your shared module specially if they provide services.

The Angular team even recommends to avoid providing services in shared modules. If you go that route, you still have the forRoot alternative.

Friday, June 16, 2017

Let's talk about Dependency Injection (DI) in Angular. I'd like to take a different approach and tell you the stuff that surprise me when I've first learned them using Angular on larger apps...

Key feature from Angular even since AngularJS (ie: Angular 1.X), DI is a pure treasure from Angular, but injector hierarchy can be difficult to grasp at first. Add routing and dynamic load of modules and all could go wild... Services get created multiple times and if stateful (yes functional lovers, you sometimes need states) the global states (even worse 😅) is out of sync in some parts of your app.
To get back in control of the singleton instances created for your app singleton, you need to be aware of a few things.

Let's get started...

Tour of hero app

Let's reuse the tour of heroes app that you should be familiar with from when you first started at angular.io.
Thansk to LarsKumbier for adapting it to webpack, I've forked the repo and adjust it to my demo's needs. All source code could be find on github.

In this version of Tour of heroes, the app displays a Dashboard page and a Heroes page. I've added a RecentHeroCompoent that displays the recently selected heroes in both pages. This component uses the ContextService to store the recently added heroes.

See AppModule in master branch.

Provider at Component level

Let's go to HeroSearchComponent in src/app/hero-search/hero-search.component.ts file and change the @Component decorator:

Run the app again.
What do you observe?
The heroes page is working fine listing below the recently visited heroes. However going to Dashboard/SearchHeroComponent, the recently visited heroes list is empty!!

The recently added heroes is empty in HeroSeachComponent because you've got a different instance of ServiceContext. Dependency injection in Angular relies on hierarchical injectors that are linked to the tree of components.
This means that you can configure providers at different levels:

for the whole application when bootstrapping it in the AppModule. All services defined in providers will share the same instance.

for a specific component and its sub components. Same as before but for à specific component. so if you redefine providers at Component level, you got a different instance. You've overriden global AppModule providers.

Tip: don't have app-scoped services defined at component level. Very rare use-cases where you actually want

Provider at Module level

What about providers at module level, if we do something like:

Let's first refactor the code, to introduce a SharedModule as defined in angular.io guide.
In your SharedModule, we put the SpinnerComponent, the RecentHeroComponent and the ContextService. Creating the SharedModule, you can clean up the imports for AppModule which now looks like:

Full source code in github here.
Notice RecentHeroComponent and SpinnerComponent has been removed from declarations. Intentionally the ContextService appears twice at SharedModule and AppModule level. Are we going to have duplicate instances?

Nope.
A Module does not have a specific injector (as opposed to Component which gets their own injector). Therefore when AppModule provides a service for token ContextService and imports a SharedModule that also provides a service for token ContextService, then AppModule's service definition "wins". This is clearly stated in AppModule angular.io FAQ.

Where to go from there

In this blog post you've seen how providers on component plays an important role on how singleton get created. Modules are a different story, they do not provide encapsulation as component.
Next blog posts, you will see how DI and dynamically loaded modules plays together. Stay tuned.

Tuesday, May 30, 2017

You're done with a first beta of your angular 4 app.
Thanks to Test Your Angular Services and Test your Angular component, you get a good test suite 🤗. It runs ok with a npm test on your local dev environment. Now, is time to automate it and have it run against a CI server: be Travis, Jenkins, choose your weapon. But most probably you will need to run you test headlessly.

Until recently the only way to go is to use PhantomJS, a "headless" browser that can be run via a command line and is primarily used to test websites without the need to completely render a page.

Since Chrome 59 (still in beta), you can now use Chrome headless! In this post we'll see how to go headless: the classical way with PhamtomJS and then we'll peek a boo into Chrome Headless. You may want to wait for official release of 59 (it should be expected to roll out very soon in May/June this year).

Getting started with angular-cli

Let's use angular-cli latest release (v1.0.6 at the time of writing), make sure you have install it in [1].

Rerun, tada !
It works!
... Until you run into a next polyfill error. PhantomJS is not the latest, even worse, it's getting deprecated.
Even PhantomJS main maintainer Vitali is stepping down as a maintainer recommending to switch to chrome headless.
It's always cumbersome to have a polyfilll need just for your automated test suite, let's peek a boo into Headless Chrome.

Chrome headless

First of all, you either need to have Chrome beta installed or have ChromeCanary.
On Mac:

Friday, May 19, 2017

In my previous post "Testing your Services with Angular", we saw how to unit test your Services using DI (Dependency Injection) to inject mock classes into the test module (TestBed). Let's go one step further and see how to unit test your components.

With component testing, you can:

either test at unit test level ie: testing all public methods. You merely test your javascript component, mocking service and rendering layers.

or test at component level, ie: testing the component and its template together and interacting with Html element.

I tend to use both methods whenever it makes the more sense: if my component has large template, do more component testing.

Another complexity introduced by component testing is that most of the time you have to deal with the async nature of html rendering. But let's dig in...

Setting up tests

I'll use the code base of openshift.io to illustrate this post. It's a big enough project to go beyond the getting started apps. Code source could be found in:
https://github.com/fabric8io/fabric8-ui/. To run the test, use npm run test:unit.

Component test: DI, Mock and shallow rendering

In the previous article "Testing your Services with Angular", you saw how to mock service through the use of DI. Same story here, in TestBed.configureTestingModule you define your testing NgModule with the providers. The providers injected at NgModule are available to the components of this module.

For example, let's add a component test for CodebasesAddComponent a wizard style component to add a github repository in the list of available codebases. First, you enter the repository name and hit "sync" button to check (via github API) if the repo exists. Upon success, some repo details are displayed and a final "associate" button add the repo to the list of codebases.

In line [2], you use useValue to inject a value (created via dynamic mock with jasmine) or use a had crafted class in [3] to mock your data. Whatever is convenient!

In line [4], you use NO_ERRORS_SCHEMA and in line [1] we declare only one component. This is where shallow rendering comes in. You've stubbed services (quite straightforward thanks to Dependency Injection in Angular). Now is the time to stub child components.

Shallow testing your component means you test your UI component in isolation. Your browser will display only the DOM part that directly belongs to the component under test. For example, if we look at the template we have another component element like alm-slide-out-panel. Since you declare in [1] only your component under test, Angular will give you error for unknown DOM element: therefore tell the framework it can just ignore those with NO_ERRORS_SCHEMA.

Note: To compile or not to compile TestComponent?
In most Angular tutorials, you will see the Testbed.compileComponents, but as specified in the docs this is not needed when you're using webpack.

Async testing with async and whenStable

Let's write your first test to validate the first part of the wizard creation, click on "sync" button, display second part of the wizard. See full code in here.

In [4] and [5], you trigger an event for the component to be initialized. As the the HTML rendering is asynchronous per nature, you need to write asynchronous test. In Jasmine, you used to write async test using done() callback that need to be called once you've done with async call. With angular framework you can wrap you test inside an async.

In [6] you notify the component a change happened: user entered a repo name, some validation is going on in the component. Once the validation is successful, you trigger another event and notify the component a change happened in [7]. Because the flow is synchronous you need to chain your promises.

Eventually in [8] following given-when-then approach of testing you can verify your expectation.

Async testing with fakeAsync and tick

Replace async by fakeAsync and whenStable / then by tick and voilà! In here no promises in sight, plain synchronous style.

When DI get tricky

While writing those tests, I hit the issue of a component defining its own providers. When your component define its own providers it means it get its own injector ie: a new instance of the service is created at your component level. Is it really what is expected? In my case this was an error in the code. Get more details on how dependency injection in hierarchy of component work read this great article.

What's next?

In this post you saw how to test a angular component in isolation, how to test asynchronously and delve a bit in DI. You can get the full source code in github.
Next post, I'll like to test about testing headlessly for your CI/CD integration. Stay tuned.
Happy testing!

Second, lots of talks about the Cloud with OpenShift, Kubernetes, Docker in prod, Cloud Foundry and even some clusters battle with chaos monkey. 🐵🙈🙉🙊

The first day started with the keynote from the RivieraDEV team where Sebastien with a virtual Mark Little, announced the first joined edition with JUDCon. To follow, Nadir Kadem's
presentation on hacking culture and Hendrik Ebbers beautifully crafted slides on a project life gives the tone of RivieraDEV: a conference for developers.

With 3 tracks, you have to make a call, here are the presentations I've picked.

Edson Yanaga's session on Kubernetes and OpenShift. The presentation starts form Forbes' quote: "Now every company is a software company" and focus on how to organize your team using the right tools to deliver the best business value to end users. A/B testing, features toggle, monitoring is made easy with OpenShift with a zero downtime deployment.

Nodejs on OpenShift by Lance Ball who shows case how to do a source to image on OpenShift console and get the latest nodejs version available. the presentation also illustrates with a short demo on circuit breaker for your micro services in nodejs.

Lunch break with socca: if you don't know what it is, you ought to come to 2018 edition and taste it!

Stephanie Moallic talks about how to control a robot from a hand crafted ionic2 mobile app. From under 100 euros you can get you arduino-based robot! The only limit you have is your imagination.

Francois Teychene tells us his experience on running Docker on production clusters. So, with docker you can't get rid of your ops department?

Jean-françois Garreau demos the new physical web API. Lots of new cool stuff to try out to enhance your web site UX with some vibration, notification...

Last presentation is a BOF session on Monade where Philippe, Nicolas, Guillaume and Gauthier illustrate functions like map, switchMap with bottles, pears and alcohol. If you don't get fluent on functional programming, I'll put it on the drinks.

For the second day, Matthias kills the rumour on the French Riviera weather:

The keynotes starts on accessibility and quality by Aurelien Levy, a subject very often overlooked. You, as a developer have the power to change other person's life. To carry on "with great powers come great responsibilities", Guillaume Champeau talks about ethics in IT and the privacy concern when googling.
Again, with 3 tracks, here are the presentations I've picked.

Julien Viet talsk about Http2 multiplexing theory. With a very visual demo of http1 vs http2 verticles loading in high latency images. Here is the link: http2-showcase! Also I get out of the presentation, with the willing to dig a bit more GRPC with protocol buffer to even encode better and reduce payload.

To follow, Thomas presents Reactive programming with Eclipse Vert.X. With a live demo, he shows a verticle with reactive wrapper. I've learned about Single RxJava class, a special case of single-event Observable. I need to dig in Thomas' music store demo.

Back for some docker, with skynet vs monkey planet fight. I really enjoy the light tone of the presentation.

Josh Long demos how to deploy on Cloud Foundry using AB testing, zuul configuration... Nice demo, I'm even on the demo. Thanks my friend 😊

Some CSS novelties with GridLayout, I'm not yet ready for it, still learning. Thanks Raphael for the nice intro, quite in-depth some time, I'll need to review some slides.

So this is the end, time to say good-bye my friends. Thanks to all our speakers to join us to make a great edition. Last but not least, thanks to all the attendees for coming and make the edition so special: best attendee record this year, over 400!
See you all for 2018 edition.

PS: If you want to read more blog post on RivieraDEV, I recommend Fanny's post.

Tuesday, May 9, 2017

Have you ever joined a project to find out it is missing unit tests?
So as the enthusiastic new comer, you've decided to roll your sleeves 💪 and you're up to add more unit tests. In this article, I'd like to share the fun of seeing the code coverage percentage increased 📊 📈 in your angular application.

When starting testing a #UnitTestLackingApplication, I think tackling Angular Services are easier to start with. Why? Some services might be self contained object without dependencies, or (more frequently the only dependencies might be with http module) and for sure, there is no DOM testing needed as opposed to component testing.

Setting up tests

I'll use the code base of openshift.io to illustrate this post. It's a big enough project to go beyond the getting started apps. Code source could be found in:
https://github.com/fabric8io/fabric8-ui/

npm test // to run all test
npm run test:unit // to run only unit test (the one we'll focus on)
npm run test:debug // to debug unit test

When starting a test you'll need:

to have an entry point, similar to having a main.ts which will call TestBed.initTestEnvironment,
this is done once for all your test suite. See spec-bundle.js for a app generated using AngularClass starter.

you also need a "root" module similar (called testing module) to a root module for your application. You'll do it by using TestBed.configureTestingModule. This is something to do for each test suite dependent on what you want to test.

Let's delve into more details and talk about dependency injection:

Dependency Injection

The DI in Angular consists of:

Injector - The injector object that exposes APIs to us to create instances of dependencies. In your case we'll use TestBest which inherits from Injector.

Provider - A provider takes a token and maps that to a factory function that creates an object.

Dependency - A dependency is the type of which an object should be created.

Let's add unit test for Codebases service. The service Add/Retrieve list of code source. First we need to know all the dependencies the service uses so that for each dependencies we define a provider. Looking at the constructor we got the information:

The service depends on 4 services and one configuration string which is injected. As we want to test in isolation the service we're going to mock most of them.

How to inject mock TestBed.configureTestingModule

I choose to use Logger (no mock) as the service is really simple, I mock Http service (more on that later) and I mock AuthenticationService and UserService using Jasmine spy. Eventually I also inject the service under test CodebasesService.

One thing important to know is that with DI you are not in control of the singleton object created by the framework. This is the Hollywood concept: don't call me, I'll call you. That's why to get the singleton instance created for CodebasesService and MockBackend, you need to get it from the injector either using inject as below:

To be or not to be

Notice how you get the instance created for you from the injector TestBed. What about the mock instance you provided with useValue? Is it the same object instance that is being used? Interesting enough if your write a test like:

line 1 will fail whereas line 2 will succeed. Jasmine uses toBe to compare object instance whereas toEqual to compare object's values. As noted in Angular documentation, the instances created by the injector are not the ones you used for the provider factory method. Always, get your instance from the injector ie: TestBed.

By adding an HttpModule to our testing module in line [1], the providers for Http, RequestOptions is already configured. However, using an NgModule’s providers property, you can still override providers (line 2) even though it has being introduced by other imported NgModules.
With this second approach we can simply override XHRBackend.

We start with given: Angular’s http module comes with a testing class MockBackend. No http request is sent and you have an API to mock your call. Using connection.mockResponse we can mock the response of any http call. We can also mock failure (a must-have to get a 100% code coverage 😉) with connection.mockError.

The when is simply about calling our addCodebase method.

The then is about verifying the expected versus the actual result. Because http call return RxJS Observable, very often service's method that use async REST call will use Observable too. Here our addCodebase method return a Observable. To be able to unwrap the Observable use the subscribe method. Inside it you can access the Codebase object and compare its result.

What's next?

In this post you saw how to test a angular service using http module. You can get the full source code in github.
You've seen how to set-up a test with Dependency Injection, how to mock http layer and how to write your jasmine test.
Next blog post, we'll focus on UI layer and how to test angular component.

Thursday, April 27, 2017

I've just started getting my fingers in Angular. I've worked briefly with AngularJS in the past. Although, I'm doubtless - you know the saying: testing is doubting 😁
I've always started looking at new framework with unit testing in mind.
In this post, I'll use Google team term Angular stands for post 2.0, in there I'll use the latest release ie: 4.0.

When writing test, it is sometimes useful to debug the test using devtools (come on... no console log, vintage time is over 👾👾👾).
Let's see how to debug your test suite with Karma... It all depends on how your started your project:

Now just run npm run test:debug. Karma is now in single mode therefore Chrome stays opened!
Easy to debug simply cmd + alt + I to open devtools.
Also, note that the coverage report is ran and now visible!

NOTE: npm test is an alias to ng test (as most projects nowadays use npm script. Very handy as you don't need to globally install ng-cli!)

ng test will bring chrome as per default. Easy to debug simply cmd + alt + I to open devtools. Open your favourite editor, change the code. The tests are re-run.
Easy-peasy, not much to do. What about if you want to run the coverage tool?
From angular-cli wiki:

ng test --code-coverage --single-run

karma.conf.js the source of truth

In the end, it all boils down to karma.conf.js configuration file. Wether by default you're running continuously in watch mode (dev friendly) or your test run with PhantomJS (CI/CD friendly), this is up to Karma configuration. It is however always good to have a build command to override and offer dev and CI friendly build.