Forem: Jo Hanna Pearce

How to Test Five Common NgRx Effect Patterns

Jo Hanna Pearce — Fri, 08 May 2020 13:08:37 +0000

0. Test Harness Setup
1. Non-Dispatching Tap Effect
2. Dispatching SwitchMap Effect
3. Multi-Dispatch Effect
4. Store Dependent Effect
5. Timed Dispatch Effect

⚠️ Requirements

I'm going to assume that you know something about Angular development with TypeScript and at least a little about the NgRx library and the Redux pattern. You might gain some insight from reading through these patterns if you're at the beginning of your journey with these technologies but I don't intend this to be introductory.

I don't necessarily expect this article to be read from start to end. Consider it reference material, which is why I've linked the patterns at the start.

🤯 Introduction

I've been using NgRx with Angular for a few years now and yet still every time I come to testing effects, my mind will often go blank. It's not that tests for effects are particularly arcane, I think it comes down to cognitive load and the Redux-style pattern itself. We know that there's a limited amount of things we can process at any one time, and there is already so much going on in my head trying to manage actions, reducers and selectors, not to mention the complexities of understanding RxJS pipes that trying to cram testing into my head on top of that just causes my brain to stall.

One way I try to solve this problem is by having working template examples to hand.

📋 Copy/Paste Driven Development

A lot of people deride this kind of technique as programming without thinking, but you know what? I'm ok with that. I don't want to have to think about what I'm writing all the time. Sometimes, I know the overall shape of what I need to build. I know which pieces I need to put together, but faffing around with the intricacies of how I do that can be a distraction.

Think back to learning about the ternary operator for example:

const x = y ? 1 : 0;

How long was it before that started to feel natural? (If it even does?) When I started programming, that felt like a little bit of extra complexity that I didn't need. I'd often have to look up how it was used elsewhere in the code to confirm that I was using it correctly!

Having reference code to hand that you know functions correctly is extremely useful, and not just for the novice programmer. You can copy that code and then start modifying it. You know that you're starting from correct behaviour and you don't have to question everything about how you're writing the code, just the pieces you're changing.

This isn't a strategy that's going to work for everything, but I find that when using NgRx (and reactive programming in general) it can be extremely useful as you find yourself writing very similar code over and over again.

If you want to refer to some working code while checking out these patterns, I created a workspace here: https://github.com/jdpearce/ngrx-effects-patterns

0. Test Harness Setup

The workspace I created uses Jest but you could just as easily use Jasmine for testing. Much of the code would be similar except for the spies. I also use jasmine-marbles for Observable testing in most cases, but I won't use any particularly complicated syntax, I use it in the most basic way possible where I can get away with it.

Most effects spec files will be initially set up as follows (imports are omitted for brevity) :

describe('ThingEffects', () => {
  let actions: Observable<any>;

  // These are the effects under test
  let effects: ThingEffects;
  let metadata: EffectsMetadata<ThingEffects>;

  // Additional providers - very basic effects tests may not even need these
  let service: ThingService;
  let store: MockStore<fromThings.ThingsPartialState>;

  beforeEach(async(() => {
    const initialState = {
      // You can provide entirely different initial state here
      // it is assumed that this one is imported from the reducer file
      [fromThings.THINGS_FEATURE_KEY]: fromThings.initialState,
    };

    TestBed.configureTestingModule({
      providers: [
        ThingEffects,
        ThingService,
        provideMockActions(() => actions))
        provideMockStore({ initialState: initialAppState }),
      ],
    });

    effects = TestBed.inject(ThingEffects);
    metadata = getEffectsMetadata(effects);
    service = TestBed.inject(ThingService);
    store = TestBed.inject(Store) as MockStore<fromThings.ThingsPartialState>;
  }));
});

This should look like a standard Angular test harness but without any component under test. provideMockActions and provideMockStore are crucial for helping us test effects. It was truly the dark times before these existed.

1. Non-Dispatching Tap Effect

performThingAction$ = createEffect(
  () =>
    this.actions$.pipe(
      ofType(ThingActions.performThingAction),
      tap(() => this.thingService.performAction())
    ),
  { dispatch: false }
);

This is an effect that only does one thing. It calls a service when receiving a particular action. We use tap here because we don't want to modify the stream in any way. We could change the stream however we like because NgRx isn't going to pay attention to the output, but it's good practice to leave the stream alone unless we have some reason to change it.

1.1 Testing for non-dispatch

All effects have metadata attached and one of the pieces of metadata is whether or not we expect that effect to dispatch another action.

We can test this by looking at the metadata directly :

it('should not dispatch', () => {
  expect(metadata.performThingAction$).toEqual(
    expect.objectContaining({
      dispatch: false,
    })
  );
});

1.2 Testing the service call is made

it('should call the service', () => {
  // set up the initial action that triggers the effect
  const action = ThingActions.performThingAction();

  // spy on the service call
  // this makes sure we're not testing the service, just the effect
  jest.spyOn(service, 'performAction');

  // set up our action list
  actions = hot('a', { a: action });

  // check that the output of the effect is what we expect it to be
  // (by doing this we will trigger the service call)
  // Note that because we don't transform the stream in any way,
  // the output of the effect is the same as the input.
  expect(effects.performThingAction$).toBeObservable(cold('a', { a: action }));

  // check that the service was called
  expect(service.performAction).toHaveBeenCalled();
});

⚠️ NB - If we want to cover all the bases we might write another test to check that this effect only fires when ThingActions.performThingAction() is emitted. I don't tend to do this, as it's just testing whether NgRx ofType works and whether you've remembered to add it. However, if this is the kind of thing you find you or your team are missing often, feel free to add that test and bring the lack of it up in code reviews.

2. Dispatching SwitchMap Effect

getThings$ = createEffect(() =>
  this.actions$.pipe(
    ofType(ThingActions.getThings),
    switchMap(() =>
      this.thingService.getThings().pipe(
        map((things) => ThingActions.getThingsSuccess({ things })),
        catchError((error) => of(ThingActions.getThingsFailure({ error })))
      )
    )
  )
);

If you've used NgRx before this may look extremely familiar. An action comes in which triggers something like an API call. This call will either succeed or fail and we dispatch a success or failure action as a result. In large NgRx codebases you might have this kind of effect all over the place.

⚠️ NB - Depending on what dispatches the initial getThings action, you may want to use concatMap instead here. This is something that would probably be more important for a call which updated the backend rather than simply fetched data.

2.1 Successful service call

it('should get the items and emit when the service call is successful', () => {
  // set up the initial action that triggers the effect
  const action = ThingActions.getThings();

  // set up our dummy list of things to return
  // (we could create real things here if necessary)
  const things = [];

  // spy on the service call and return our dummy list
  jest.spyOn(service, 'getThings').mockReturnValue(of(things));

  // set up our action list
  actions = hot('a', { a: action });

  // check that the observable output of the effect is what we expect it to be
  expect(effects.getThings$).toBeObservable(
    cold('a', { a: ThingActions.getThingsSuccess({ things }) })
  );
});

⚠️ NB - It doesn't actually matter whether we use hot or cold here. If more than one thing was going to subscribe to the effect it might actually make a difference, but that doesn't happen here. The difference between hot and cold observables can be extremely confusing and it may make no sense that within these tests it seems irrelevant, but sorting out that particular Gordian knot is beyond the scope of this article. Just know that this code, for the moment at least, does the job. (I don't want to encourage cargo cult development though, so when you have bandwidth to dig into the difference, there's a good article by Ben Lesh that goes into detail)

2.2 Unsuccessful service call

it('should emit an error action when the service call is unsuccessful', () => {
  // set up the initial action that triggers the effect
  const action = ThingActions.getThings();

  const error = 'There was an error';

  // spy on the service call and return an error this time
  spyOn(service, 'getThings').and.returnValue(throwError(error));

  // set up our action list
  actions = hot('a', { a: action });

  // check that the output of the effect is what we expect it to be
  expect(effects.getThings$).toBeObservable(
    cold('a', { a: ThingActions.getThingsFailure({ error }) })
  );
});

This is pretty similar to the previous test except we've sneaked in usage of the throwError function. You can follow the link for more detail but all it does is create an observable that immediately emits an error notification, which is exactly what we want to mock as a return value from our getThings method.

3. Multi-Dispatch Effect

initialiseThing$ = createEffect(() =>
  this.actions$.pipe(
    ofType(ThingActions.initialisingAction),
    switchMap((_action) => this.thingService.getThings()),
    switchMap((things) => {
      const actions: Action[] = [];
      if (!!things) {
        actions.push(ThingActions.getThingsSuccess({ things }));
      }
      actions.push(ThingActions.initialiseComplete());
      return actions;
    })
  )
);

Sometimes you need to dispatch more than one action. Again the choice of switchMap or concatMap (or even mergeMap) is very much context dependent, the important thing here is that one action goes in and one or more come out.

⚠️ NB - This also illustrates a slightly magical feature of switchMap where if you return any array-like object from the projection, it will automagically treat it like an observable of the objects in the array. In this case it's like switching to an Observable<Action>. If you find this confusing (and I wouldn't blame you here) you can replace return actions; with return from(actions); instead (cf. from).

3.1 Testing for multiple action output

it('should emit initialiseComplete & getThingsSuccess if thing is found.', () => {
  const things = [
    {
      id: '1',
      name: 'Thing 1',
    },
  ];
  jest.spyOn(service, 'getThings').mockReturnValue(of(things));

  actions = hot('a', { a: ThingActions.initialisingAction() });
  const expected = cold('(bc)', {
    b: ThingActions.getThingsSuccess({ things }),
    c: ThingActions.initialiseComplete(),
  });

  expect(effects.initialiseThing$).toBeObservable(expected);
});

This shows the usage of a sync grouping. That is, groups of notifications which are all emitted together. In this case, our getThingsSuccess and initialiseComplete. I've used this kind of pattern before to end an initialisation sequence of actions without making the last action do double-duty. Being able to fork your actions like this can be extremely useful if you have main sequences of actions with optional side quests being triggered (that's how I think of them).

3.2 Testing single action output

it('should just emit initialiseComplete if no things are found.', () => {
  const things = [];
  jest.spyOn(service, 'getThings').mockReturnValue(of(things));

  actions = hot('a', { a: ThingActions.initialisingAction() });
  const expected = cold('a', { a: ThingActions.initialiseComplete() });

  expect(effects.initialiseThing$).toBeObservable(expected);
});

This should look familiar. There's nothing new introduced here at all! Yay!

4. Store Dependent Effect

storeReadingEffect$ = createEffect(
  () =>
    this.actions$.pipe(
      ofType(ThingActions.thingsModified),
      withLatestFrom(this.store.pipe(select(selectThings))),
      map(([_action, things]) => this.thingService.persistThings(things))
    ),
  { dispatch: false }
);

Sometimes you end up needing to pull a value from the store. Don't feel bad about that. It's actually extremely common! In this case we're using withLatestFrom which means that every time we get a thingsModified action, we grab the latest state and selectThings from it. To test this, we need to provide some state and that's where provideMockStore and the MockStore come into play.

it('should read things from the store and do something with them', () => {
  const things = [
    {
      id: '1',
      name: 'Thing 1',
    },
  ];

  // Note here that we have to provide a ThingsPartialState
  // not just a ThingsState.
  store.setState({
    [fromThings.THINGS_FEATURE_KEY]: {
      log: [],
      things,
    },
  });

  jest.spyOn(service, 'persistThings').mockReturnValue(of(things));

  actions = hot('a', { a: ThingActions.thingsModified() });

  expect(effects.storeReadingEffect$).toBeObservable(cold('a', { a: things }));

  expect(service.persistThings).toHaveBeenCalledWith(things);
});

The only new thing here is that we call store.setState. This is a wonderous boon to the test writing developer. In the old times we would actually dispatch actions to build up store state, but that would require those actions and associated reducers already existed and you would end up tightly coupling your tests to unrelated code. This is much simpler and neater (and it means you can write tests when the actions and reducers that might populate that slice of the store don't even exist yet).

5. Timed Dispatch Effect

timedDispatchEffect$ = createEffect(() =>
  this.actions$.pipe(
    ofType(ThingActions.startThingTimer),
    delay(ThingsEffects.timerDuration),
    mapTo(ThingActions.thingTimerComplete())
  )
);

This is a slightly contrived example, but I have done similar things in the past. One particular case involved waiting for a few seconds so that a user could read a notification before they were redirected elsewhere.

To test this we need to abandon marbles though!

it('should dispatch after a delay (fakeAsync)', fakeAsync(() => {
  actions = of(ThingActions.startThingTimer());

  let output;
  effects.timedDispatchEffect$.subscribe((action) => {
    output = action;
  });

  expect(output).toBeUndefined();

  tick(ThingsEffects.timerDuration);

  expect(output).toEqual(ThingActions.thingTimerComplete());
}));

Angular handily provides us with the fakeAsync function which lets us control the flow of time. delay has its concept of time based on the scheduler it uses, so in order to test this with marbles we would have to (somehow) tell it that we want to use the TestScheduler alongside hot and cold rather than the default async Scheduler. This wouldn't be a trivial thing to do as often these kinds of operators are buried deep in your effect and you really don't want to have to start injecting schedulers into your effects. It's simpler just to discard marbles entirely and test it with fakeAsync.

With fakeAsync we set up a normal subscription to the effect as we would in non-test code and then trigger it by ticking forward time with a function appropriately called tick. When we tick far enough, the observer will be triggered, output will be populated and we can check that it matches what we expect!

That brings us to the end of these patterns with the important point that there is always another way to test them. You don't have to use marbles at all, in fact it could be argued that they make things more complicated for these kinds of cases not less! That decision is up to you. Don't worry too much about what you decide as long as it makes sense to you. There's never any point in sticking with something you find confusing. Do what works for you.

As always, if you have any questions, corrections or comments, feel free to get in touch here or on Twitter.

TIL: HTMLLinkElement.href returns more than you think...

Jo Hanna Pearce — Tue, 21 Apr 2020 16:29:59 +0000

I recently came across a bit of code that was trying to change the favicon on every route change of a single page application.

i.e. Every time the URL changed from /users to /users/fred a function would run that checked the current favicon href and updated it if necessary.

It did this with a tiny bit of javascript like this:

// where `expectedHref` is something like '/favicon-shop.ico'

const link = document.querySelector('link[rel*=icon]');
if (link.href !== expectedHref) {
    link.href = expectedHref;
}

What I noticed was that it was changing the favicon with every route change. Why?

It turns out that the href property on an HTMLLinkElement always returns the full URI of the linked resource rather than just the content of the href attribute!

We should have been using getAttribute instead 🤦‍♀️

link.href; // = 'http://example.com/favicon.ico'
link.getAttribute('href'); // = '/favicon.ico'

15 Minute Nx on a bed of Clouds

Jo Hanna Pearce — Wed, 15 Apr 2020 17:07:31 +0000

With all the focus these days on home cooking, I thought I'd write up a recipe of my own which you can follow without even having to go into the kitchen.

For those of you craving the taste of a real monorepo, this recipe combines Nx with a continuous integration service and then adds some fresh Nx Cloud for a piquant dash of the efficiency that comes with computation memoization.

If it's not clear what computation memoization is or how it can help you, then this could be the recipe for you!

Unlike a standard recipe the product of following this set of instructions should be understanding. The quality of what you create as a result of combining all the ingredients together doesn't matter. You could love or hate the result, but what I hope you'll come away with is a little more knowledge. That's what writing this achieved for me.

I want to emphasise that I describe this as a recipe because there is no single right way to combine all these ingredients. What follows is something that worked for me. If you find any problems, errors or just have questions, feel free to tweet me @jdpearce.

⚠️ Requirements

There is only so much I can explain without making this article unwieldy, so I'll assume that anyone reading this has some understanding of JavaScript development and already has Node and npm installed. You can use another package manager if you like, but I'm only going to provide instructions for the lowest common denominator.

I am going to assume you have some idea what a monorepo actually is and why you might want to use one. Following this recipe may give you some insight into how they can be used, but I'm not going to go into detail about the pros and cons.

While I list having a GitHub account as an ingredient, I'm not going to explain how to set up new repositories and I will assume a certain amount of knowledge of git itself. There are better articles out there which can go into detail about this. If you run into problems I will always recommend "Oh Shit, Git!?!" 😁

🥬 Ingredients

1 x Nx (Extensible Dev Tools for Monorepos) workspace (v9.2.2 as of writing)
1 x Nx Cloud (Computation Memoization in the Cloud) account
1 x CircleCI (Continuous integration) account
1 x GitHub account
Back and/or front end frameworks to taste (I'm going to use React and Express)

🥒 Preparation

Before we start, I recommend that you have accounts with CircleCI, Nx Cloud and GitHub ready. You don't want to ruin the flow of a good home cooking session by having to run out to the shops and generate new passwords.

Make sure your CircleCI account is connected to your GitHub account. You can achieve that via the Account Integrations dashboard.

I'm going to assume that you also have Nx installed globally. You don't need to do this, you can just as easily use npx nx or yarn nx to call it, but it does mean I have to write less. To install with npm:

npm install -g @nrwl/cli

Now that we're all prepared, let's get cooking!

1. Creating the Nx Workspace (Monorepo)

⏱ 3 minutes

Find a place on your file system where you want to create the new workspace and run the following command:

npx create-nx-workspace@latest nx-cloud-recipe

You'll be asked a set of questions for the kind of workspace you want to create. I'm going to choose the react-express preset which will create two applications; a React front end and an Express API. You can call the front end application whatever you like, but I'll go with todos as that seems to be fairly standard ~~tutorial~~ recipe fare, and I'll just select CSS as the default stylesheet format for now.

Once the creation script has worked its magic, you should find a new workspace with an initialised git repository in the nx-cloud-recipe folder.

cd nx-cloud-recipe

To check that everything is set up as expected, why not run a test:

nx test todos

On my machine this runs in a couple of seconds and the output looks like this:

Or we could run all the tests in the monorepo:

nx run-many --target=test --all

The output of that should look something like this:

You should find that the output for this command is generated almost instantaneously. This is because Nx locally caches the output of certain computational tasks, such as in this case running tests. There only happens to be one test suite in the entire monorepo and we just ran it and therefore cached it.

If we make changes to the todos application, the same command will be smart enough to recognise that something has changed and the test will be run.

You can pause here if you wish to get a feel for this particular ingredient. Try running both applications and seeing the output at http://localhost:4200 -

nx serve api & nx serve todos

⚠️ NB You'll need to run these in different instances of cmd/powershell if you're running on Windows. Alternatively, you could investigate the power of run-commands, but that's beyond the scope of this recipe for the moment.

2. Push Your Monorepo to GitHub

⏱ 2 minutes

Create a new, empty repository on GitHub, I've called mine the same as the local monorepo, but you don't have to (you could call it bob or alice if you really wanted 🤷‍♀️). After you've done that, come back to the local command line to push the generated code:

git remote add origin https://github.com/jdpearce/nx-cloud-recipe.git
git push -u origin master

⚠️ NB Don't try to push to my repo, I don't think you'll be allowed. Copy the link to your own repository from the screen that GitHub helpfully shows you with all the possible ways you can push code to it.

3. Connect to CircleCI

⏱ 2 minutes

Go to your CircleCI dashboard and select "Add Projects". This should bring you to a page something like this where you can search for the new GitHub repository that you've just created:

ℹ️ NB If the repository doesn't appear in the list, you may have to refresh the page.

Click on the "Set up Project" button and then select the "Node" configuration template:

Next we have to click the appallingly badly named "Start Building" button, which does nothing of the sort:

We're going to let CircleCI create a new branch called circleci-project-setup and commit a new file .circle/config.yml

Click on the "Add Config" button and let it do it's thing.

⚠️ NB I am not a big fan of YAML. I think it's difficult to write and more importantly difficult to read. Be warned that there is unfortunately quite a bit of it coming up. YMMV, of course...

4. Adding `build` and `test` jobs

⏱ 5 minutes

At your local command line:

git fetch
git checkout circleci-project-setup

We're going to cheat a little here. Detailed configuration of CircleCI is far beyond the scope of this recipe so I'm going to provide you with a store-bought configuration that sets up both build and test jobs. There are many ways to do this, so don't believe for a moment that this is the best or only way to achieve this goal. If you have the time artisanal, hand-crafted YAML is the way to go, but store-bought is fine for now.

ℹ️ NB Deployment is also beyond the scope of this recipe, but my colleague Rares Matei is publishing something covering deployment in the near future.

Using your editor of choice, replace the contents of the .circleci/config.yml file with the following:

version: 2.1

orbs:
  node: circleci/node@2.0.1

# Reusable Commands
commands:
  npm_install:
    description: 'Install & Cache Dependencies'
    steps:
      - run: npm install
      - save_cache:
          key: nx-cloud-recipe-{{ checksum "package-lock.json" }}
          paths:
            - ~/.cache
            - node_modules

  restore_npm_cache:
    description: 'Restore Cached Dependencies'
    steps:
      - restore_cache:
          keys:
            - nx-cloud-recipe-{{ checksum "package-lock.json" }}
            - nx-cloud-recipe- # used if checksum fails

  setup:
    description: 'Setup Executor'
    steps:
      - checkout
      - attach_workspace:
          at: ~/project

# Available Jobs
jobs:
  initialise:
    executor:
      name: node/default
    steps:
      - checkout
      - restore_npm_cache
      - npm_install
      - persist_to_workspace:
          root: ~/project
          paths:
            - node_modules
            - dist

  build:
    executor:
      name: node/default
    steps:
      - setup
      - run:
          name: Build all affected projects
          command: npx nx affected:build --base=master --head=HEAD

  test:
    executor:
      name: node/default
    steps:
      - setup
      - run:
          name: Run all affected tests
          command: npx nx affected:test --base=master --head=HEAD

workflows:
  build-and-test:
    jobs:
      - initialise
      - build:
          requires:
            - initialise
      - test:
          requires:
            - initialise

😱

This is a really scary amount of YAML and personally I find it difficult to read. CircleCI's documentation is pretty unhelpful for the novice too, so I'll try to briefly explain what's going here.

At the top level we have groupings of orbs, commands, jobs and workflows. In the orbs group we indicate that we're using the circleci/node@2.0.1 orb, which is a collection of bits and pieces for working with node projects. In particular it includes the default executor which is the environment used to run the jobs.

The commands group declares and defines three commands that can be used within jobs:

npm_install - runs a standard dependency installation and populates a local cache
restore_npm_cache - restores from that local cache
setup - checks out the code and restores a workspace

The jobs group declares and defines three jobs that we can sequence within workflows:

initialise - check out the code, restore caches, run an npm install command and then persist all this to the workspace
build - builds all the affected projects
test - tests all the affected projects

ℹ️ NB It's worth noting here that the build and test jobs use nx affected logic to decide which projects to build or test. Nx is smart enough to know which projects have been touched by a particular commit (or range of commits) and will run the appropriate target for those projects only. This should save you considerable amounts of time in your CI environment. In this case we're only running build and test for those projects which have changes when comparing between HEAD and the current master branch, so this should work well for pull requests.

Lastly, the workflows group defines a single workflow called build-and-test which specifies that the initialise job must be run before either build or test can be run.

If you save, commit, and push this to GitHub, you should see something like this in CircleCI:

🎉

If everything looks good as above, we can get that configuration into the master branch with a pull request.

ℹ️ NB You could make this workflow run only when a pull request is created, but that (along with many other configuration niceties) is beyond the scope of this recipe. Still, this is one of the many aspects of this recipe that you can experiment with later! 🧪

5. Connect to Nx Cloud

⏱ 3 minutes

The first step is to go to your Nx Cloud dashboard and create a new workspace. I've called mine the same as the repository, but again you don't have to do this if you're not really bothered about naming¹.

Once you've named the workspace, you'll be presented with this set of instructions for CI and local configuration. I've blocked out the tokens in the screenshot above so that nefarious web users don't store their caches in my workspace and use up my Nx Cloud Coupons (you should get 5 hours free when you first sign up).

We're now going to add that local read-only token to our nx-cloud-recipe repository:

git checkout master
git pull
git checkout -b nx-cloud-configuration
npm install @nrwl/nx-cloud && nx g @nrwl/nx-cloud:init --token=<token>

(The last line here should be copied and pasted from the "Set up for local development" section shown above)

Next we need to add the read-write token to our CircleCI setup:

(You can find this by selecting the "Workflows" section on the left and then clicking the little cog icon next to the nx-cloud-recipe workflow)

CircleCI is now ready for you to commit and push the nx-cloud-configuration branch:

git commit -am "feat: add nx cloud configuration"
git push --set-upstream origin nx-cloud-configuration

This should result in a beautiful green set of workflow steps which means you're ready to create a pull request and merge that back into master!

Time now for you to sit back, pour a glass of something enjoyable and serve the completed dish...

🍇 Taste the Fruits of Your Labour!

Nx and its affected logic has your back when it comes to saving time in your continuous integration environment. When it comes to saving developer time locally, that's where Nx Cloud can really shine.

Check out the repo into a new folder, e.g.

cd ..
git clone https://github.com/jdpearce/nx-cloud-recipe.git nx-cloud-recipe2
cd nx-cloud-recipe2
npm install

⚠️ NB I'd rather you didn't clone my repository, but you can if you want. I make no guarantees about it having valid coupons on the account though, so you may not see any effect.

This repo shouldn't have any local cache since we haven't run build or test here before, however, if we try building everything:

nx run-many --target=build --all

You should see almost instant output:

With the new Nx Cloud configuration in place, and because you haven't yet made any changes to the repository, the build process you run locally would be identical to the one that was run in CI, so Nx will read from the cache that was generated when the build ran in CI, saving us the amount of time it would normally have taken to run!

If we check back on the Nx Cloud site, you should be able to see that we've had an impact on the graph:

A whole MINUTE saved! 🤯

Ok, maybe that's not hugely impressive in this case, but then we did create this workspace mere minutes ago.

ℹ️ NB One minute is the smallest unit that the chart labels will actually display, but the chart is drawn with finer precision, which is why the "minute" saved in build is bigger than the "minute" saved in test 🤓

Imagine how much time you would save if this were a mature workspace with numerous apps and libraries². We've seen cases where in only weeks, teams have saved hundreds of hours of developer time. That's your time, and that means more time for you to do the things you care about.

Naming is, of course, one of the two hardest problems in computer science. Those being: ↩
1. Naming things
2. Cache invalidation
3. Off-by-one errors
You don't actually have to imagine this. The following chart shows that over two weeks one particular team of 20-30 saved enough time to make up a whole extra developer! ↩

Forem: Jo Hanna Pearce

How to Test Five Common NgRx Effect Patterns

⚠️ Requirements

🤯 Introduction

📋 Copy/Paste Driven Development

0. Test Harness Setup

1. Non-Dispatching Tap Effect

1.1 Testing for non-dispatch

1.2 Testing the service call is made

2. Dispatching SwitchMap Effect

2.1 Successful service call

2.2 Unsuccessful service call

3. Multi-Dispatch Effect

3.1 Testing for multiple action output

3.2 Testing single action output

4. Store Dependent Effect

5. Timed Dispatch Effect

TIL: HTMLLinkElement.href returns more than you think...

15 Minute Nx on a bed of Clouds

⚠️ Requirements

🥬 Ingredients

🥒 Preparation

1. Creating the Nx Workspace (Monorepo)

⏱ 3 minutes

2. Push Your Monorepo to GitHub

⏱ 2 minutes

3. Connect to CircleCI

⏱ 2 minutes

4. Adding build and test jobs

⏱ 5 minutes

5. Connect to Nx Cloud

⏱ 3 minutes

🍇 Taste the Fruits of Your Labour!

4. Adding `build` and `test` jobs