Forem: peerhenry

Typesafe mockable globals in Vue3

peerhenry — Fri, 29 Apr 2022 10:42:48 +0000

Typically in large apps there are plenty of things that you need global access to throughout the codebase; things like locale, environment, feature flags, settings etc. Then there are also functions that are useful to be globally accessible, like notifications, console actions or formatters. Then - assuming you are working with typescript - it's nice to have all of them properly typed. And finally - assuming you are writing tests (for example using jest or vitest) - it's nice if all of this can be properly controlled (mocked) in automated tests.

How do we achieve this?

Let's say my application is called 'Peer'. I will begin by defining an interface that will contain some useful globals; specifically a string that we can use for date formatting and some console actions¹ :

PeerGlobals.ts

export interface PeerGlobals {
  log: (m: string) => void
  logError: (m: string) => void
  defaultDateFormat: string
}

Then I will implement and provide it in a plugin:

PeerPlugin.ts

import { App, Plugin } from 'vue'
import { PeerGlobals } from 'PeerGlobals'

export const PeerPlugin: Plugin {
  install(app: App) {
    const globals: PeerGlobals = {
      log: console.log,
      logError: console.error,
      defaultDateFormat: 'yyyy-MM-dd',
    }
    app.provide('globals', globals)
  }
}

main.ts

import { createApp } from 'vue'
import App from './App.vue'
import { PeerPlugin } from './PeerPlugin'

const app = createApp(App)
// use any other plugin here like Router or Pinia
app.use(PeerPlugin)
app.mount('#app')

Now in any component we can do this:

MyComponent.vue

<script lang="ts" setup>
import type { PeerGlobals } from '@/PeerGlobals'

const globals = inject('globals') as PeerGlobals
</script>

As for testing, I will make a file mockPeerGlobals.ts which I can then use in any test that mount any components that depend on these globals:

mockPeerGlobals.ts

import type { PeerGlobals } from '@/PeerGlobals'

export const mockPeerGlobals: PeerGlobals = {
  log: () => {},
  logError: () => {},
  defaultDateFormat: 'yyyy-MM-dd',
}

MyComponent.spec.ts

import { mount } from '@vue/test-utils'
import { mockPeerGlobals } from 'mockPeerGlobals'
import MyComponent from '@/components/MyComponent.vue'

function mountMyComponent() {
  return mount(MyComponent, {
    global: {
      provide: {
        globals: mockPeerGlobals
      }
    }
  })
}

// ...tests

Assertions on global functions

in mockPeerGlobals.ts the log functions are empty stubs, but typically you will want to replace them with mock functions so you can assert that they have been called as expected - (for example using jest.fn() in jest or vi.fn() in vitest). Just be sure to properly reset all mocks before running a test.

Using `window` and `document`

Sometimes we need access to window and document, which is typically not available within a test environment. Therefore it is useful to also put these behind our global interface. However these objects contain a huge amount of properties, so mocking those will be way too much work. Instead we can use some typescript magic called mapped types to make all properties optional:

PeerGlobals.ts

type MockWindow = {
  [k in keyof Window]?: Window[k]
}

type MockDocument = {
  [k in keyof Document]?: Document[k]
}

export interface PeerGlobals {
  window: (Window & typeof globalThis) | MockWindow
  document: Document | MockDocument
  // ...other globals
}

Now in our mock globals we only need to implement the functions that are relevant for our tests. Supposing querySelectorAll is the only one we are using:

mockPeerGlobals.ts

import type { PeerGlobals } from '@/PeerGlobals'

export const mockPeerGlobals: PeerGlobals = {
  window: {},
  document: {
    querySelectorAll: () => []
  },
  // ...other globals
}

What if we want mock implementations on a per test basis?

Exporting a mock object as we did in mockPeerGlobals.ts is somewhat restrictive: All tests are forced to use the same globals object. But sometimes we need test-specific mock implementations. Let's change mockPeerGlobals.ts to support this, where we will use a helper function from the Ramda library; mergeDeepRight:

mockPeerGlobals.ts

import { mergeDeepRight } from 'ramda'
import type { PeerGlobals } from '@/PeerGlobals'

// ...define default globals

export function getMockPeerGlobals(overrides?: Partial<PeerGlobals>): PeerGlobals {
  return mergeDeepRight(mockPeerGlobals, (overrides as any) || {})
}

Now in a test we can override any property on any level of nesting, without affecting the rest of the globals:

MyComponent.spec.ts

import { mount } from '@vue/test-utils'
import { mockPeerGlobals } from 'mockPeerGlobals'
import MyComponent from '@/components/MyComponent.vue'

function mountMyComponent() {
  return mount(MyComponent, {
    global: {
      provide: {
        globals: getMockPeerGlobals({
          document: {
            querySelectorAll: () => []
          }
          // the rest of globals remain unaffected
        })
      }
    }
  })
}

// ...tests

Putting console actions behind an interface is useful for preventing logs being printed in our test output. ↩

Integration testing Vue3 with Pinia

peerhenry — Thu, 07 Apr 2022 14:38:55 +0000

I was working on a Vue 3 project where I had to write an integration test with vue test utils for a component that relied on Pinia, while at the same time needing to set some initial state on a Pinia store before mounting that component. This caused a problem:

The component could not mount before a Pinia store was configured,
The Pinia store could not be configured before the component would be mounted. Read why in this paragraph of the official docs of vue test utils.

One solution would be to refactor the code so that the component would not rely on a store when mounting. But that would be too much work and would also be too restrictive for our codebase. We should not have to restrict access to stores in component lifecycle hooks!

So in this post another solution is presented, which is rendering the component inside of a wrapper component specifically designed for integration tests:

IntegrationTestWrapper.vue

<script setup lang="ts">
import { useMyStore } from '@/stores/myStore'

// === setup any Pinia stores here ===
useMyStore().$patch({ foo: 'bar' })
// ======

defineProps(['component'])
</script>

<template lang="pug">
component(:is="component")
</template>

Then inside of our test we can write:

MyComponent.spec.ts

import { flushPromises, mount } from '@vue/test-utils'
import { createPinia } from 'pinia'

describe('MyComponent', () => {
  it('should mount', async () => {
    const wrapper = await mount(IntegrationTestWrapper, {
      props: {
        component: 'MyComponent', 
        anotherProp: 'abc', // will be passed to child component
      },
      global: {
        plugins: [createPinia()], // initializes Pinia
        stubs: { MyComponent }
      },
    })
    await flushPromises() // make sure all promises in lifecycle hooks are resolved
    expect(wrapper.exists()).toBe(true)
    // further assertions
  })
})

Now everything is done in the correct order:

Pinia is created and initialized before IntegrationTestWrapper is mounted.
IntegrationTestWrapper initializes store state before mounting MyComponent.
Props given to IntegrationTestWrapper will be passed down to MyComponent.

Notes:

IntegrationTestWrapper is not rendering a slot because that would not receive the props.
You cannot just call createPinia() before configuring store state, you will receive an error that Pinia is not initialized with app.use(). It is only initialized in tests through mounting options.

Deploy Node to Azure with Git

peerhenry — Sat, 21 Aug 2021 15:28:43 +0000

Web applications can be deployed to Azure Web Apps with git, where you only need to push your built files. So you don't need to push your source files. This is useful for automated deployment. This article will demonstrate how to achieve this with a Node application.

Part 1: Creating the App Service in Azure

1.1 Go to portal.azure.com and log in.
1.2 Click "Create a resource".

1.3 Select "Web App".

1.4 Select your subscription and Resource Group.
1.5 Fill out a unique name.
1.6 Under Publish select "Code".
1.7 Under Runtime stack select "Node 14 LTS".
1.8 Under Operating System select "Linux".
1.9 Under Region, select one that falls under your App Service Plan

1.10 Select the service plan that suits your application. If you are just testing go with "Free F1".
1.11 Click "Review + create".
1.12 Click "Create".

Part 2: Configuring the App Service in Azure

2.1 After your resource is created click "Go to resource".
2.2 Click "Deployment Center".

2.3 Under Source select "Local Git".

2.4 Click Save.
2.5 Navigate to "Local Git/FTPS credentials".

2.6 Under Application Scope find Username. Remember the part after the slash \, it will start with a dollar sign $. In the example from the image below, it will be "$dummy928". I'll refer to this later as <user>.
2.7 Remember the password. I'll refer to this later as <password>.

2.8 Go back to Settings, and remember the value under "Git Clone Uri" without https://. I'll refer to this later as <git url>.

Part 3: Deploying to the App Service using Git

3.1 Create a folder with a file server.js and add the following snippet:

var http = require("http");
var port = 8080;

http
  .createServer(function (request, response) {
    response.writeHead(200, { "Content-Type": "text/plain" });
    response.end("Hello Dummy App Service! \n");
  })
  .listen(port);

Notes:

Port must be 8080.
Script must be named server.js or app.js.
Alternatively your application start script can be named differently if you add a package.json with a run script.

3.2 Run git init .
3.3 Run git add .
3.3 Run git commit -am 'dummy commit' or a different commit message if you like.
3.4 Run git remote add azure 'https://<user>:<password>@<git url>'. Note that the single quotes are important to prevent the dollar sign from being interpreted as an environment variable.
3.5 Run git push azure master -f
3.6 Back in Azure within the App Service, go to "Overview" and click the value under "URL". This will navigate to your Node server and you should see something like the image below.

Note that the first visit might take a while to load because the container needs to start.

Part 4 Notes for automated deployment.

Steps 3.2 to 3.5 can be defined within an automation pipeline to set up automated deployment. If you are using a build system to generate your node application script - with tools like typescript, webpack, rollup or similar - don't forget to switch to your build directory first: the git commands must be executed from your build output folder. Also keep in mind the notes after step 3.1.

As a final note on automated pipelines, please make sure you hide the credentials <user> and <password> behind protected variables. For example, using Gitlab you would use secret CI/CD variables.

Have fun deploying!

Provide/inject services in Vue

peerhenry — Fri, 02 Apr 2021 16:12:15 +0000

introduction

Vue components are nice as long as they stay small, but it's easy to end up with "fat" components if you're not careful. Components quickly become bulgy as soon as they exceed 200 lines of code, and that happens quite easily when you need to interact with an API. Luckily, business logic that doesn't strictly need to be inside a component (whose single responsibility should be rendering a template) can be extracted in various ways. Leveraging Vuex would be one. You can use mixins or the composition API, but for the purposes of this article we are interested in moving the logic to a service class that we move to a separate script. While we could import such a script directly into our component, that strategy is coupled rather tightly, which is not nice if you want to properly unit test your component. Now mocking your ES6 imports is not impossible, but it's a hassle and I don't recommend it if you can avoid it. This article suggests a strategy leveraging Vue's provide/inject mechanism to decouple service classes from components.

Define a service

For this example let's define a service with an async save method:

export default class DummyService {
  async save(model) {
    // do some mapping
    // make call using an api client
  }
}

Register the service

You can use a wrapper component, or define this in the root vue instance:

export default Vue.createApp({
  provide: {
    dummyService: new DummyService()
  },
  // other options
})

Inject the service

Here is the script part for an example vue component making use of our dummy service:

export default {
  name: 'DummyComponent',
  data() {
    return {
      isSaving: false,
      model: { dummy: 'dummy' }
    }
  },
  inject: ['dummyService'],
  methods: {
    async save() {
      this.isSaving = true
      const response = await this.dummyService.save(this.model)
      // handle response
      this.isSaving = false
    }
  }
}

Mock the service in your unit tests

Now inside our unit test for DummyComponent we can do:

const mockDummyService = {
  async save() {}
}

const wrapper = shallowMount(DummyComponent, {
  provide: {
    dummyService: mockDummyService
  }
})

You could use mock functions inside mockDummyService (for example those from jest) to make assertions about when and how your service is being called if you like.

But what if I need to use stuff from the Vue instance?

No worries. What you can do is setup a second Vue instance after having configured Vue which you then inject into your service. Let's adjust our example so our DummyService uses a number of globally accessible things on the vue instance. Let's suppose:

Vue.prototype.$apiClient = new MyApiClient()
Vue.prototype.$now = () => new Date()

After any such configuration simply create a Vue instance and inject it into any services:

const secondaryVue = new Vue()

...

export default Vue.createApp({
  provide: {
    dummyService: new DummyService(secondaryVue)
  },
  // other options
})

Then for the service:

export default class DummyService {
  constructor(vue) {
    this.vue = vue
  }

  async save(model) {
    model.timeStamp = this.vue.$now()
    return await this.vue.$apiClient.save(model)
  }
}

Through this vue instance, you also get access to any Vue plugins like Vuex - as long as you set them up before you create the Vue instance. This way the service and vue instance also remain nicely decoupled: You can write proper unit tests for DummyService using a mock object for the vue instance you inject.

In the introduction I mentioned some alternative approaches, so let me explain their limitations compared to this approach:

Using Vuex or composition API: You won't have access to the vue instance, and there are no straightforward ways of injecting dependencies.
Using mixins: obscures who owns the method or data you are calling, and can cause naming conflicts.

That's all, cheers!

Setup Cypress and Auth0 for SPA's

peerhenry — Mon, 22 Mar 2021 11:07:41 +0000

How to setup Cypress for end to end testing an SPA that is locked behind an Auth0 login. Auth0 has a blogpost explaining this setup here. However, if you're building a single page application you are most likely depending on @auth0/auth0-spa-js for managing your login state. This means we need to get the token into our auth0 client. This post will demonstrates how we can achieve that using localstorage.

Setup Auth0 and Cypress

First of all we need to configure Auth0 so that we can retrieve a token with an API request. To do this follow the steps in the paragraph Auth0 Setup & Configuration from the Auth0 blogpost about Cypress.

Add a file cypress.env.json to your cypress project root folder and fill it out with your auth0 application and user data.

{
  "auth_audience": "",
  "auth_url": "",
  "auth_client_id": "",
  "auth_client_secret": "",
  "auth_username": "",
  "auth_password": ""
}

Don't forget to add it to your .gitignore!

Then add a command to /cypress/support/commands.js:

Cypress.Commands.add('login', (overrides = {}) => {
  Cypress.log({
    name: 'loginViaAuth0',
  });

  const options = {
    method: 'POST',
    url: Cypress.env('auth_url'),
    body: {
      grant_type: 'password',
      username: Cypress.env('auth_username'),
      password: Cypress.env('auth_password'),
      audience: Cypress.env('auth_audience'),
      scope: 'openid profile email',
      client_id: Cypress.env('auth_client_id'),
      client_secret: Cypress.env('auth_client_secret'),
    },
  };
  cy.request(options);
});

Enable Auth0's localstorage for caching

Now somewhere in your SPA you will have:

import createAuth0Client from '@auth0/auth0-spa-js'

...

this.auth0Client = await createAuth0Client(authOptions)

This is where you should enable localstorage. The parameter authOptions is an object that can contain cacheLocation, which we just need to set to 'localstorage'. Note that saving tokens in localstorage is a security concern. Therefore we will only use localstorage for non-production environments. For production we will use cacheLocation: 'memory', which is also the default if you don't provide it.

const cacheLocation = process.env.NODE_ENV === 'production' ? 'memory' : 'localstorage'
const optionsWithCache = {
  ...authOptions,
  cacheLocation,
}
this.auth0Client = await createAuth0Client(optionsWithCache)

This also means Cypress login will only work in non-production environments, so I hope you don't need to run Cypress on your production environment.

The login test

describe("login", () => {
  it("should successfully log into our app", () => {
    cy.login()
      .then((resp) => {
        return resp.body;
      })
      .then((body) => {
        const { access_token, expires_in, id_token, token_type } = body;
        cy.visit("/", {
          onBeforeLoad(win) {
            const keyPrefix = "@@auth0spajs@@";
            const defaultScope = "openid profile email";
            const clientId = Cypress.env("auth_client_id");
            const audience = "default";
            const key = `${keyPrefix}::${clientId}::${audience}::${defaultScope}`;
            const decodedToken = {
              user: JSON.parse(
                Buffer.from(body.id_token.split(".")[1], "base64").toString(
                  "ascii"
                )
              ),
            };
            const storageValue = JSON.stringify({
              body: {
                client_id: clientId,
                access_token,
                id_token,
                scope: defaultScope,
                expires_in,
                token_type,
                decodedToken,
                audience,
              },
              expiresAt: Math.floor(Date.now() / 1000) + body.expires_in,
            });
            win.localStorage.setItem(key, storageValue);
          },
        });
      });
  });
});

A few things to note from this snippet:

cy.visit("/") assumes you've set baseUrl in cypress.json. For example in my case testing locally:

{
  "baseUrl": "http://localhost:3020"
}

The key and storageValue need to be of a specific format in order for the Auth0 client to pick it up. The snippet contains the default values for keyPrefix, defaultScope and audience. Don't worry about their peculiar values. Unless you're tinkering with scope or audience when creating your Auth0 client you don't need to change those.

Happy testing!

Functional programming in typescript using fp-ts: ReaderTaskEither

peerhenry — Thu, 10 Sep 2020 07:11:10 +0000

This article will demonstrate how to leverage the fp-ts library to make async requests in typescript using functional programming.

Say we want to make an HTTP request. From that we know at least the following:

We need an HTTP client to make the call.
We need to handle a Promise.
We need to anticipate errors.

Let's reiterate those three points, this time in terms of what they signify.

A dependency.
An asynchronous call.
Something that can go wrong.

In functional programming we use certain data types to deal with these types of complexity. In our case specifically:

Reader - for dependency injection.
Task - for asynchronous things.
Either - for things that can go wrong.

We could compose these monads ourselves, but fp-ts provides us with some useful compositions out of the box, like the ReaderTaskEither. That is a Reader containing a Task containing an Either. Let's go over them and see what we can do with their composition.

Note: The code snippets containing a describe block can be executed with Jest or Jasmine.

1. Reader

Reader<A, B> is just a function from A to B. But having that type alias is very useful: it means we want to do dependency injection.

import * as R from 'fp-ts/lib/Reader'

describe('Reader', () => {
  it('should just be a function', () => {
    const myReader: R.Reader<number, string> = (a: number) => String(a)
    expect(myReader(15)).toBe('15')
  })
}

If you know dependency injection then you are probably used to injecting class instances into constructors to build up a dependency tree, after which you send in the parameters from a top level function that will then traverse the tree. This means dependencies get injected first and function parameters get passed second. In functional programming it goes the other way around. We first inject the parameters in order to create a function of external dependencies. Only then do we send in those dependencies to execute the pipe. Let's see how this works in practice:

Note that the types HttpClient and Response are hypothetical.

// imperative example
class MyController {
  private HttpClient client
  constructor(HttpClient client) {
    this.client = client
  }

  async fetch(path: string): Response {
    return await this.client.get(path)
  }
}

// ...

const controller = new MyController(new HttpClient()) // inject dependencies
const res: Response = await controller.fetch('events') // pass parameters and execute

// functional example
import * as R from 'fp-ts/Reader'

// ...

const fetch = (url: string) =>
      R.asks((client: HttpClient) => client.get(url))
const fetchEvents = fetch('events') // pass parameters
const res: Response = await fetchEvents(new HttpClient() // inject depdencies and execute

asks<A, B>(f) will return a reader that will provide A as a parameter to f, which in turn must return a B.

You can find a more detailed explanation of the Reader monad in this article: Getting started with fp-ts: Reader.

A note on pipelines

That last example was straightforward, but operations like that involve more logic before and after our fetch function. In functional programming we use pipelines to compose functions for more complicated operations. With fp-ts we can use pipe or flow for that. We can rewrite fetchEvents as follows:
// with pipe
const fetchEvents = pipe('events', fetch)

// with flow
const fetchEvents = flow(fetch)('events')
With pipe and flow we can easily put more functions in:

Put them in front of fetch for things we want to do to the > events parameter before calling fetch.

Put them after fetch for things we want to do to the result of calling fetch.

2. Task

A Task is a function that returns a Promise. That way we can defer execution of the Promise until we call upon the Task.

import * as T from 'fp-ts/lib/Task'

describe('Task', () => {
  it('of should work', async () => {
    // Arrange
    const mytask = T.of('abc')
    // Act
    const result = await mytask()
    // Assert
    expect(result).toEqual('abc')
  })

  it('should work with promise', async () => {
    // Arrange
    const mytask: T.Task<string> = () => Promise.resolve('def')
    // Act
    const result = await mytask()
    // Assert
    expect(result).toEqual('def')
  })
})

3. Either

Either is a way of anticipating failures. It has two instances; left and right - left indicating a failure and right indicating that everything is OK.

import * as E from 'fp-ts/lib/Either'

describe('Either', () => {
  it('of should create a right', () => {
    // Act
    const myEither = E.of('abc')
    // Assert
    expect(myEither).toEqual(E.right('abc'))
  })
})

Either has some helper constructors, like fromNullable which returns a left if the parameter is null or undefined.

import * as E from 'fp-ts/lib/Either'

describe('Either.fromNullable', () => {
  const errorMessage = 'input was null or undefined'
  const toEither = E.fromNullable(errorMessage)

  it('should return right with string', async () => {
    // Arrange
    const expected = 'abc'
    // Act
    const myEither = toEither(expected)
    // Assert
    expect(myEither).toEqual(E.right(expected))
  })

  it('should return left with undefined', async () => {
    // Act
    const myEither = toEither(undefined)
    // Assert
    expect(myEither).toEqual(E.left(errorMessage))
  })
})

4. Task + Either = TaskEither

TaskEither is an Either inside of a Task, meaning it's an asynchronous operation that can fail. It provides us with the useful function tryCatch that takes two parameters: The first is a function that returns a promise, the second is function that maps the rejected result to something that ends up in a left - we'll just use the String constructor for that in this example:

import * as TE from 'fp-ts/lib/TaskEither'
import * as E from 'fp-ts/lib/Either'

describe('TaskEither', () => {
  it('should work with tryCatch with resolved promise', async () => {
    // Arrange
    const expected = 135345
    // Act
    const mytask = TE.tryCatch(() => Promise.resolve(expected), String)
    const result = await mytask()
    // Assert
    expect(result).toEqual(E.right(expected))
  })

  it('should work with tryCatch with rejected promise', async () => {
    // Arrange
    const expected = 'Dummy error'
    // Act
    const mytask = TE.tryCatch(() => Promise.reject(expected), String)
    const result = await mytask()
    // Assert
    expect(result).toEqual(E.left(expected))
  })
})

Click here to go to an extensive article about Task, Either and TaskEither.

5. Reader + Task + Either = ReaderTaskEither

Now let's put the parts together to create a functional data structure that we can use to make an HTTP request. Let's begin with a naive approach:

import * as TE from 'fp-ts/lib/TaskEither'

const client = new HttpClient()
const myTryCatch = TE.tryCatch(() => client.get('events'), String)

We refactor to parameterize the client and the url, using currying.

const myTryCatch = (url: String) => (client: Client) => TE.tryCatch(() => client.get(url), String)

Let's declare the type of this function:

type MyTryCatch = (url: string) => (client: HttpClient) => TE.TaskEither<string, Response>
const myTryCatch: MyTryCatch = (url) => (client) => TE.tryCatch(() => client.get(url), String)

Now we are going to rewrite the type using Reader:

type MyTryCatch = (url: string) => Reader<HttpClient, TE.TaskEither<string, Response>>

And as you've probably guessed, a Reader returning a TaskEither is a ReaderTaskEither:

import * as RTE from 'fp-ts/lib/ReaderTaskEither'

type MyTryCatch = (url: string) => RTE.ReaderTaskEither<HttpClient, string, Response>

This is a single type that tells you all you need to know about the logic it encapsulates:

It has a dependency on HttpClient
The error gets formatted to a string
A successful execution will result in a Response

Seeing it in action

The nice thing about Reader is that we can obtain the dependency anywhere in a pipe using asks, which we've discussed earlier in this article. This is how it would work:

import * as RTE from 'fp-ts/lib/ReaderTaskEither'
import * as TE from 'fp-ts/lib/TaskEither'
import * as R from 'fp-ts/lib/Reader'

// ...

pipe(
  // ...functions leading up to a ReaderTaskEither containing a userId
  RTE.chain((userId) =>
    R.asks((client: HttpClient) => TE.tryCatch(() => client.get(`user/${userId}`), String))
  )
  // ...functions handling the response
)

Typically you would extract this function to make the pipe more readable.

pipe(
  // ...
  RTE.chain(fetchUser)
  // ...
)

// ...

const fetchUser = (userId: string) => (client: HttpClient) => TE.tryCatch(() => client.get(`user/${userId}`), String))

If chain is unfamiliar to you, it takes a function that maps whatever the monad is holding and returns a monad of something else. In this example it is assumed we start with a ReaderTaskEither of a string userId and we chain it to a ReaderTaskEither of a Response. For more information about monads and chain in fp-ts checkout Getting started with fp-ts: Monad

Conclusion

Doing functional programming in typescript is not required and therefore a discipline. Nothing is forcing you to use a ReaderTaskEither for asynchronous operations, but the reward is a function that you can use in any pipe that by its signature is honest about what it does. It also makes for excellent testability: by using Reader we don't have to worry about instantiating a class that may or may not require more dependencies than we care about for a given test.

Checkout the official documentation for more information.

Why I quit coffee

peerhenry — Wed, 29 Apr 2020 16:58:02 +0000

About six months ago I quit coffee cold turkey. I must say, over the years I've come across many difficult situations as a developer, but man, few have ever been as difficult as quitting coffee. I quit because I found out I was addicted, and what shocked me even more was the fact that I had been completely oblivious to it.

part 1 - quitting

The decision to quit came minutes after I discovered that I was addicted. It was a random weekend like any other, but I felt exhausted and I was nagging my girlfriend: "What is wrong with me?". She replied:

"Is it because you haven't had any coffee in the last two days?"

That hit me like a ton of bricks. I could feel in my bones that was exactly what it was. I had become physically dependent on caffeine - which in my book pretty much defines an addiction. And all those moments when I randomly felt tired or sleepy suddenly made sense.

Now, I must admit that I was perhaps a bit naive. If you're drinking ten coffee every day like I was, you probably shouldn't be very surprised that it's going to have an effect on you. Nevertheless it surprised me. Feeling like a smart, strong and healthy individual made me the least bit worried that something as harmless as coffee was ever going to be anything other than an tasty warm beverage. I mean how bad can it be if everyone is drinking it all the time? Do me a favor, close your eyes for a second and imagine a colleague coming by your desk for a quick chat. Is that colleague holding a cup of coffee? How often do you have the oppertunity each day to get a coffee? I wouldn't be the least bit surprised if there are more streets worldwide where you can buy a coffee than there are streets where you can't. If you search for "list most consumed beverages in the world" then any list you will find will have coffee in the top three. Couple that with the fact that there is barely any warning about the adverse effects of coffee, and you've got a recipe for creating generations of caffeine addicts.

part 2 - withdrawal

From what I've seen and read on the internet, quitting cold turkey is the least pleasant way of quitting, and I can understand why. Most people recommend gradually taking it down, like one less coffee every couple of days or so. I didn't really believe that would work for me so I just stopped drinking at once. The result was two days of exhaustion and headaches and I slept on the couch during the day. After that it took about one to two weeks to get back to normal. So the withdrawal wasn't terrible, but surely not something I had expected from coffee.

Ever since I quit my focus and my energy level is more stable. There are no more random moments of drowsiness, and the urge I once had to drink coffee also disappeared over time. Although there are still plenty of times when I feel like I could enjoy a nice cup of coffee. I sometimes pass by a coffee factory near where I live. It emits a powerful scent of coffee and every time I think, "man it would be nice to have a coffee now".

I also found myself not knowing what to drink instead. Going for a coffee had become a such a habit that I actually had to come up with what else I was going to drink.

part 3 - developers and coffee

Being a developer is a job that requires focus, attention and clarity of thought. Caffeine definitely interferes with that. So it seems paradoxical to me that being a developer is almost synonymous to being a coffee junkie. But it's actually not that surprising. Caffeine is an easy remedy whenever you feel sleepy, and it increases your focus in the short term. And that sure comes in handy whenever you need that extra boost to solve whatever problem you're working on. But there's a debt to be payed. That sleepiness you have suppressed will come back harder when that caffeine wears out. What will you do then? Drink more coffee? Eventually you will end up as I did: being sleepy all the time and drinking coffee all the time.

I'm not saying you shouldn't drink coffee if you're a developer. This story is just a warning to those who are as uninformed about the impact of caffeine as I was. So that the next time you want to grab a cup, you might think twice.

Setup Xdebug on WSL

peerhenry — Wed, 29 Apr 2020 14:18:42 +0000

How to setup xdebug in Windows Subsystem for Linux (WSL). Open your terminal and let's get cracking!

1. Update pecl
sudo pecl channel-update pecl.php.net

2. Install xdebug
sudo pecl install xdebug

3. Find xdebug.so
cd /usr
find . -name xdebug.so
In my case it was /usr/lib/php/20180731/xdebug.so

4. Edit your php.ini
Edit the php.ini file for the php version you are using. I had to edit /etc/php/7.3/cli/php.ini but you may be using a different version. If you are unsure, you can find out by running php -i|grep 'php.ini' in the terminal. That should show you where to find you active php.ini file. Now add the following lines to the end of that file:

[Xdebug]
zend_extension="/usr/lib/php/20180731/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000

But make sure you enter the correct path to xdebug.so specified in step 3. Choose another port if you feel like it.

5. Setup VSCode
If you are using VSCode like I do, this last step is for you. Inside your project folder, check if you have a folder .vscode that contains launch.json. If not, click the run button on the left panel. Then click on "create a launch.json file" and select "PHP". In case your project is located in your windows file system instead of your WSL file system - which is the case for me - make sure you add pathMappings.

"pathMappings": {
    "/mnt/<DRIVE>/<PATH_TO_PROJECT>": "<DRIVE>:\\<PATH_TO_PROJECT>"
},

In my case my launch.json looks like this:

{
  "version": "0.2.0",
    {
      "name": "Listen for XDebug on WSL",
      "type": "php",
      "request": "launch",
      "pathMappings": {
        "/mnt/c/infi": "C:\\Infi"
      },
      "port": 9000
    }
  ]
}

Make sure the port matches with the one you specified in step 4. Happy debugging!

Putting GraphQL Playground in front of AppSync

peerhenry — Sun, 23 Feb 2020 09:12:18 +0000

Prerequisite knowledge: Node, NPM and AWS AppSync

AWS AppSync is a service for hosting a GraphQL API with cool features like being able to generate backend resources based on a schema. We can inspect and debug that API from the queries tab in the AppSync console. But there's another tool called GraphQL Playground that has a lot more features like tabs, history, prettification, complete schema inspection and custom settings. It's also nice not having to login to AWS in order to debug or play around with our GraphQL API. So let's take a look at how we can hook up GraphQL Playground to AppSync.

Step 1: Install the necessary packages

After setting up your project with npm, we are going to install the following dependencies:

npm i -S express @workpop/graphql-proxy graphql-playground-middleware-express babel-runtime

We are going to run a node server using express. Then we need a way to proxy our GraphQL API so that our queries and mutations get forwarded to AppSync. That's where @workpop/graphql-proxy comes in. This package is built for schema stitching, which is useful if you need to combine multiple GraphQL endpoints (you can read more about that in this blogpost). But for our purpose we are happy with just the proxying. Finally, graphql-playground-middleware-express will give us an endpoint for the GraphQL Playground IDE.

Step 2: Get your API details

Within the Appsync console, navigate to the Schema tab, click Export schema and choose schema.graphql. Save it to your project directory, rename the file to schema.js. Surround schema with backticks and export the string, so it will look like this:

// schema.js
module.exports = `
  <YOUR SCHEMA HERE>
`;

Now we just need the URL and Api key. Back in the Appsync console, navigate to the Settings tab and copy your API URL and a valid API key. Alternatively, if you've used Amplify to setup your API you can also get theses details by running amplify status from your terminal. You can put these values in a .env file which you can read with dotenv, but for this example we'll just put them in a javascript file:

// settings.js
module.exports = {
  API_KEY: "<your api key here>",
  API_URL: "<your endpoint here>"
};

Don't forget to add this file to your .gitignore if you're using git!

Step 3: The code

Now all that's left to do is write a little express server:

// server.js
const express = require("express");
const registerServices = require("@workpop/graphql-proxy").default;
const expressPlayground = require("graphql-playground-middleware-express").default;
const types = require("./schema.js");
const { API_KEY, API_URL } = require("./settings.js");

const SERVICE_CONFIG = {
  APPSYNC: {
    address: API_URL,
    typeDefs: types
  }
};

const PORT = 4000;
const app = express();
app.get("/playground", expressPlayground({ endpoint: "/graphql" }));

registerServices({
  SERVICE_CONFIG,
  server: app,
  masterTypeDefs: types,
  customHeaders: {
    "x-api-key": API_KEY
  },
  enableGrqphiQL: true
}).then(() => {
  app.listen(PORT, () =>
    console.log(
      `Running playground proxy on http://localhost:${PORT}/playground`
    )
  );
});

Now start your server with node server.js et voila. Happy querying!

Edit:
Note that AppSync might have some AWS directives in your exported schema which graphql-proxy cannot recognize, so you will have to remove those manually.

Forem: peerhenry

Typesafe mockable globals in Vue3

How do we achieve this?

Assertions on global functions

Using window and document

What if we want mock implementations on a per test basis?

Integration testing Vue3 with Pinia

Deploy Node to Azure with Git

Part 1: Creating the App Service in Azure

Part 2: Configuring the App Service in Azure

Part 3: Deploying to the App Service using Git

Part 4 Notes for automated deployment.

Provide/inject services in Vue

introduction

Define a service

Register the service

Inject the service

Mock the service in your unit tests

But what if I need to use stuff from the Vue instance?

Setup Cypress and Auth0 for SPA's

Setup Auth0 and Cypress

Enable Auth0's localstorage for caching

The login test

Functional programming in typescript using fp-ts: ReaderTaskEither

1. Reader

A note on pipelines

2. Task

3. Either

4. Task + Either = TaskEither

5. Reader + Task + Either = ReaderTaskEither

Seeing it in action

Conclusion

Why I quit coffee

Setup Xdebug on WSL

Putting GraphQL Playground in front of AppSync

Step 1: Install the necessary packages

Step 2: Get your API details

Step 3: The code

Using `window` and `document`