Thinking why I stopped writing, even though I had such fond memories of it. The pandemic gave me that opportunity to pause, reflect, and realize what things I used to value. Glad to see that something good is coming out of this mess.

I’ll list out my motivations, as a reminder for myself, and it may possibly inspire you to take up blogging too, dear reader.

The enjoyment of writing ​

Back in 2002 when I was a student, I was experimenting a lot with the web. Learning about HTML, CSS, PHP and documenting the process. I shared my experiences on a particular forum (good old phpBB) with other developers in the Dutch web community. People had feedback, got inspired themselves, and there was always a healthy discussion. That motivated me to take up a career in web development. I believe that positive experience led to a positive association to writing for me.

However, there’s more depth to it than that, and that leads me to these benefits.

Investigative learning ​

Taking a moment to dig a bit deeper to find out why things are the way they are, can lead to a breakthrough in my thought process. Too often in this fast paced world we take things for granted. It helps to make time to allow for our mind to wander, to go into different directions, and spark innovations. Investigating deeper, learning about things. I find that unearthing something new feels fantastic. It probably has to do something with dopamine, my guess.

Calm the mind ​

Putting thoughts to paper helps to put my mind to rest. Knowing that the thoughts are deposited somewhere, ready for the taking later. Especially since I’m a knowledge worker, having to work with my mind all day.

This means that the writeup may not be intended for others to read. It’s okay when there isn’t an immediate audience. I do it for self care.

Writing exercise ​

Formulating words in a cohesive, short, and informative matter helps my overall communication skills. Going from rambling thoughts to manicured words takes practice. After writing more, I’ve observed it becomes easier to immediately formulate my thoughts. That helps me to have better in-person conversations too.

The reward of writing ​

Looking back at when I was writing those years ago, and also thinking of similar experiences doing talks and presentations, there are nice rewards to reap after putting in the effort.

Progress as a motivator ​

It is motivating to see how I’ve grown and made progress over the years. Especially when in the tech industry it’s hard to avoid the imposter syndrome. Moreover, it invokes nostalgia, and is a good reminder that in life it is about the journey, and not the destination.

Celebrate milestones ​

I’ve often spent countless hours resolving a problem. When I do finally find the solution, the achievement can feel empty. Not all tech solutions surface itself in the UI, and documenting it in writing can give that sense of accomplishment.

Reference material ​

There have been times I found my own StackOverflow answers after an internet search. Or have been able to help a fellow dev pointing to my experiences. With a catalog of blog posts it becomes easier to tap into my past experiences.

The side-effects of writing ​

There are benefits of not keeping my thoughts to myself. It’s a vulnerable but humbling experience. It’s similar to speaking. Anyone who has stood in front of a large audience preaching their thoughts knows the anxiety. But also likely experienced the appreciation you get in return.

Community engagement ​

Software development is quite a solitary job. It is nice when I can reach out to other like-minded people. Confirmation and constructive feedback can help everyone grow. Being a lone wolf doesn’t help. Opening up to others broadens my horizons.

In addition it will grow my professional network. It allows me to meet other inspirational people. Especially when I share my content on other professional social networks also.

Showcases experience ​

And finally, after a while documenting the processes and problems and solutions I encounter, it becomes a nice showcase of my experience. Something that can’t easily be shared in a job interview. Therefore the blog becomes an extension of my CV.

This should all be plenty of reasons to keep me motivated to persist with writing on this blog. Looking forward to the journey ahead, and thank you for joining me on the ride.

Part of the provided AuthService class looks like below.

@Injectable({providedIn: 'root'})
export class AuthService {

  // Create an observable of Auth0 instance of client
  auth0Client$ = (from(
    createAuth0Client({
      domain: "example.auth0.com",
      client_id: "ABC123abc123abc123ABC",
      redirect_uri: `${window.location.origin}`
    })
  ) as Observable<Auth0Client>).pipe(
    shareReplay(1), // Every sub receives the same shared value
    catchError(err => throwError(err))
  );

The problem lies with the createAuth0Client function that is imported from the SDK. It provides access to the client object via a promise. Angular heavily depends on RXJS however, and to transform this into an observable, the from helper function is used. Other properties in the class are then chained to this observable to provide the authentication functionality.

For unit testing this is a dilemma, as it poses an external dependency that cannot be accessed. It is similar to directly using the browser's document object versus an injected Document reference in your Angular code. Instead, when the class is created, this external dependency should be injectable via the constructor so that the object can be mocked and spied upon.

Injecting the Auth0Client observable ​

Since the Auth0Client is loaded asynchronously with a promise that is wrapped as an observable, it may seem impossible to create a dependency in the constructor to Observable<Auth0Client>. However, this is possible in Angular through the use of an InjectionToken.

As of Angular 6, the InjectionToken is now tree shakable and can leverage a factory function. That makes it easy to define our injectable token:

export const AUTH0_CLIENT =
  new InjectionToken<Observable<Auth0Client>>('auth0Client$', {
    providedIn: 'root',
    factory: () => from(
      createAuth0Client({
        domain: environment.auth0.domain,
        client_id: environment.auth0.clientId,
        audience: environment.auth0.audience,
        redirect_uri: REDIRECT_URI
      })
    ).pipe(
      shareReplay(1), // Every sub receives the same shared value
      catchError(err => throwError(err))
    )
  });

Next, this token can now be injected into the constructor of the AuthService class:

constructor(
  // Use an injection token to get an observable instance
  // of the Auth0 client.
  @Inject(AUTH0_CLIENT)
  private auth0Client$: Observable<Auth0Client>,

Because the token was marked with provideIn, and referenced in the injectable AuthService, it is discovered during build and included in the compilation. There is no need to expose it with a provider in a module.

Mocking the Auth0Client in unit tests ​

With the introduction of TypeScript's Partial interface, it became a whole lot easier to mock type-safe partial implementations. With it we can mock for instance only one class function. We then can wrap that into an observable with the of helper function, and inject that into the AuthService.

const clientStub = of<Partial<Auth0Client>>({
  getTokenSilently: async () => null
});

beforeEach(() => {
  service = new AuthService(
    <Observable<Auth0Client>>clientStub,
    // etc...
  );
});

The above code mocks the result of the getTokenSilently function, to return a promise with an undefined token.

With this method it is also easy to spy on the mocks as well:

const clientStub = <Partial<Auth0Client>>{
  getTokenSilently: async () => null
};
const clientStub$ = of(clientStub);

beforeEach(() => {
  spyOn(clientStub, 'getTokenSilently').and.callThrough();
  service = new AuthService(
    <Observable<Auth0Client>>clientStub$,
    // etc...
  );
});

it('should handle custom initialization', (done: DoneFn) => {
  service.init().subscribe(
    () => {
      expect(clientStub.getTokenSilently).toHaveBeenCalled();
      done();
    },
    error => fail(`Unexpected error: ${error}`)
  );
});

Hopefully this gave you insight how to extend the AuthService class to make it possible to unit test it better.

Thanks for reading!