DEV Community: David Johnston

What are your favourite emoji to use in build pipelines?

David Johnston — Fri, 30 Sep 2022 00:00:08 +0000

I absolutely love using emojis in things like build pipelines or documentation. I find a list like this:

Run Tests
Lint
Build artefact

Is a whole lot easy to read when it has emojis:

🧪 Run tests
🔎 Lint
🏗 Build artefact

The emojis give very quick identifiable reference points - in what otherwise might look like a wall of text.

So what are your favourite emojis to use for common terms?

Here's some of mine:

Emoji	Meaning	Notes
🧪 👩🏾‍🔬	Test	It can be good to have different emojis for different test types
👷 🏗	Build
⚙️ 🔧	Configure
📦	Artefact
🔎 🕵️‍♀️	Inspect/Lint
👮🏼	Type Check	Or any other strict/grumpy check
👩‍🦯	Lint	'Lets check for things that might trip us up'
👨‍🎤	Formatting	'They're an artist'
🛃	Security check on dependencies
👩🏼‍🌾	User
🧙	Admin
🧛‍♂️	Manager

What do you think about providing Cypress and RTL selector and assertion functions alongside your components?

David Johnston — Tue, 06 Sep 2022 07:05:39 +0000

Here's an idea I've just started toying with.

So in my project the folder structure for any given component looks like this:

/MyComponent
   MyComponent.tsx - The actual component
   MyComponent.stories.tsx - Storybook stories
   MyComponent.test.tsx - RTL tests.

Fairly straight forward.

Something I've been running into recently, particularly with writing Cypress tests, is that often writing either interactions with my components (eg. click the button, select an item from the autocomplete) or assertions on them (eg. the multiselect contains value 'foo') has quite a lot friction. I'm often going into the RTL test and seeing what I've done there, and copying an modifying it.

Now I know that Testing Libraries whole philosophy is 'write tests in the way that a user would interact with the application' - but it's often not that straightforward, or it's a bit tedious.

So what I've considered is two more files along side the others;

MyComponent.rtl-selectors.ts
MyComponent.cypress-selectors.ts

These would contains functions like:

function selectItemInMultiSelect(label: string, itemName: string) //...

function assertMultiSelectContainsItem(label: string, itemName; string) //...

And the idea is, you could import these functions in your RTL/Cypress tests to assist with interactions.

Has anyone tried such a thing, and how did it go?

Cross posting from your blog to Dev.to. A good idea?

David Johnston — Sun, 11 Oct 2020 09:12:25 +0000

Been in a bit of a creative rut recently, and I'm figuring that the best thing to do, the thing I'm most inclined to do, is make blog posts about anything and everything.

I definitely want to do this as part of my own blog where I fully control the content. I've learned a lesson (nicely articulated by Austin Kleon in his book Show Your Work) when I ran a 'Humans of' page that was a Facebook page only. It now kinda sucks that all of that content is just on Facebook and I've since lost the original photos, the accompanying text only there etc. I wish I'd set up a blog like the original Humans of New York did.

So the question is - should I cross-publish all of my blog posts to Dev.to and Medium as well?

Is this a common practice? I've had a quick scroll through my Dev.to feed and I can't see many people back-linking to their blog.

As I see it:

Pros	Cons
More exposure	A bit of work setting it up programatically
Native conversation/reply functionality within the third party mediums	Back links on the posts look spammy
	Possible adverse SEO affects for the blog?

What say you?

Type widening on strings

David Johnston — Tue, 29 Sep 2020 03:23:06 +0000

The Problem

type Roles = "student" | "teacher"; 

type Person = {
    role: Roles; 
    name: string; 
    age: number; 
}

function doSomethingWithPerson(person: Person) {
    console.log(person); 
}

const andy = {
    role: "teacher", 
    name: "andy", 
    age: 31
};

doSomethingWithPerson(andy); //Argument of type '{ role: string; name: string; age: number; }' is not assignable to parameter of type 'Person'.

Playground Link

This code produces the error:

Argument of type '{ role: string; name: string; age: number; }' is not assignable to parameter of type 'Person'.
  Types of property 'role' are incompatible.
    Type 'string' is not assignable to type 'Roles'.

What's going on here?

The andy object we declare does match the type Person that the function wants, so why is TypeScript complaining?

Quick Solution

Declare the string "teacher" as const

const andy = {
    role: "teacher" as const, 
    name: "andy", 
    age: 31
};

doSomethingWithPerson(andy);

Explanation

In this scenario when we declare the object andy TypeScript infers the type of the role property as string, any string!

While "teacher" and "student" are strings, they are a subset of strings.

The Person type doesn't want any string, it wants just those two particular strings.

That TypeScript infers the type as string and not as "teacher" is called type widening.

What TypeScript is doing, is allowing for that you might later write some code like:

   andy.role = "foobar";

(That is, you're mutating the andy object).

What the as const keyword does is just prevent the type widening. See the documentation here.

What you're also doing is telling TypeScript 'don't worry, I promise I'm not going to reassign this property', and if you try, TypeScript will give you an error:

const andy = {
    role: "teacher" as const, 
    name: "andy", 
    age: 31
};

andy.role = "foobar"; //Type '"foobar"' is not assignable to type '"teacher"'.(2322)

Alternative solutions

Declare the string "teacher" as "teacher"

const andy = {
    role: "teacher" as "teacher", 
    name: "andy", 
    age: 31
};

doSomethingWithPerson(andy);

What this does is instead of using the as const keyword to prevent type widening, it just explicitly sets the type of the role property to "teacher".

Both as const and as "teacher" have the same end effect, the role property's type is "teacher".

Type inference from React.useState

David Johnston — Tue, 29 Sep 2020 02:59:19 +0000

The Problem

import React from "react";

const Foo = () => {
    const [value, setValue] = React.useState(); 
    return <input value = {value} onChange = {(e) => setValue(e.target.value)}/>
}

Playground Link

This code produces the following TypeScript error:

Argument of type 'string' is not assignable to parameter of type 'SetStateAction<undefined>'.(2345)

Quick Solution

Explicitly state the generic type:

import React from "react";

const Foo = () => {
    const [value, setValue] = React.useState<string | undefined>(); 
    return <input value = {value} onChange = {(e) => setValue(e.target.value)}/>
}

Or set the initial state to an empty string.

import React from "react";

const Foo = () => {
    const [value, setValue] = React.useState(''); 
    return <input value = {value} onChange = {(e) => setValue(e.target.value)}/>
}

(This may not be appropriate for all cases, ie maybe you really do want to leave that value undefined).

Explanation

The useState function has a generic parameter which we are not setting/declaring in the original case.

This leaves TypeScript to infer the generic type from the arguments given.

In this case useState() with no arguments, TypeScript infers the type as undefined.

TypeScript doesn't know that you later want to set a string into state here.

That is, leaving the generic parameter off is equivalent of doing:

const [value, setValue] = React.useState<undefined>();

The generic parameter determines the type of the value and setValue variables.

In this case, the setValue function is going to be the equivalent of:

function setValue(value: undefined) : void {

}

The input component doesn't like this, the event is creating has a target.value of type string.

So to solve this, we can either explicitly set the generic type, or be aware of when and how TypeScript is going to infer the generic type.

Has VS Code got worse recently?

David Johnston — Thu, 02 Jul 2020 05:30:03 +0000

While screen sharing today, a colleague commented that it seems like VS Code has got less stable in recent weeks - and that does appear to be the case.

Issues are mainly around:

Linting (Linter failing to fire and requiring a VSCode restart)
Whatever you call it when you can mouse over something for information, or CTRL/CMD + click to follow through it.

Anyone else experiencing this? Or is there some kind of code decay that would cause this?

What's the etiquette on posting to both Stack Overflow and dev.to?

David Johnston — Wed, 08 Apr 2020 07:05:07 +0000

I'm fairly new to dev.to.

I love the features and UX of Stack Exchange, but have found it quite frustrating when asking questions about software architecture and design philosophies on softwareengineering.stackexchange.com not being well received.

So where dev.to has looser 'what's on topic' requirements I'm figuring I can post here.

Now the thing is - I've recently asked a pretty technically specific question that would probably be well received on Stack Overflow -but is that considered bad form, either here or there?

What's going on with index types in TypeScript?

David Johnston — Wed, 08 Apr 2020 06:51:02 +0000

Playground link for all code here.

In TypeScript you can reference the type of an object property using the square bracket notation.

eg:



type Foo = {
   a: string;
   b: number;
   1: null;
}

type A = Foo["a"]; //string 
type B = Foo["b"]; //number
type ObjOne = Foo[1]; //null;

This also works for arrays


type MyArray = [string, number, string];

type Zero = MyArray[0]; //string 
type One = MyArray[1]; //number

Now according to the TypeScript documentation the keyof keyword returns a union type of all of those possible keys, which also includes the Array.prototype methods such as reduce, map etc.

type Reduce = MyArray["reduce"]; //type Reduce = {    (callbackfn: (previousValue: 0 | "one" | ..... 
type Length = MyArray["length"] //3

This works for ordinary objects too, but there aren't many useful native methods that exist on an object instance's prototype (Object.values etc exist as static functions on the class prototype):

type ToString = Foo["toString"]; //() => string
type Values = Foo["values"]; //Property 'values' does not exist on type 'Foo'.(2339)

Now where this gets interesting is that as well as referencing the types of properties via a string or number literal as an index - we can also reference them by a given type as an index. However, in this current example, it only works for the number type on arrays only:

type RefObjectByTypeNumber = Foo[number]; //Type 'Foo' has no matching index signature for type 'number'.(2537)
type RefObjectByTypeString = Foo[string]; //Type 'Foo' has no matching index signature for type 'number'.(2537)

type RefArrayByTypeNumber = MyArray[number]; //string | number
type RefArrayByTypeString = MyArray[string]; //Type 'MyArray' has no matching index signature for type 'string'.(2537)

If we declare an object by explicitly declaring the types of the keys, this does work:

type Bar = {
   [key: string]: string,
}; 
type RefBarByTypeString = Bar[string]; //string

type Chaz = {[key: number]: number}; 
type RefChazByTypeNumber = Chaz[number]; //number

If we declare the object keys directly as string literals, this does not work:

type Eep = {
   "a": number; 
}
type RefEepByKeyA = Eep["a"]; //number
type RefEepByTypeString = Eep[string]; // Type 'Eep' has no matching index signature for type 'string'.(2537)

It's not possible to declare both types as keys:

type Donk = {
   [keya: string]: string;
   [keyb: number]: number; //Numeric index type 'number' is not assignable to string index type 'string'.(2413)
}

Not that I necessarily want to do that.

So my main question here is - what's actually going on with how we can use types as an index - but only in specific circumstances?

The documentation from Typescript isn't particularly clear here - the only references in the documentation that I can find is is this part on index types:
https://www.typescriptlang.org/docs/handbook/advanced-types.html#index-types

which doesn't actual demonstrate using a type as an index,

and the example given here in the keyof documentation:

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-1.html

Immutable OO?

David Johnston — Fri, 27 Mar 2020 03:03:16 +0000

This talk here by Gary Bernhardt has got me thinking.

He's basically proposing what I'd call immutable object-oriented programming, where, you have model objects that contain both data, and functions, but the data is immutable.

When you do need to mutate some data, it returns a new object.

And you bundle that immutable data with helper functions that apply to just that data.

class Foo {
    private data; 
    constructor(data){
        this.data = data; 
    }

    setX(x){
         return new Foo({...this.data, x}); 
    }

    toString() {
        return `This is a Foo object with value x: ${this.data.x}`; 
    }
}

This has the advantages of easy testing, as your Object functions can still be considered pure:

    const object = new Foo({x:1}); 
    expect(object.toString).toBe("This is a Foo object with value x: 1");

And reduces a lot of cognitive load that a functional paradigm has where your data, and your functions that use that data are different things.

Eg, the equivalent code for this would be:

   setXOnFoo(foo, x) {
      return {...foo, x};  
   }

   stringifyFoo(foo) {
        return `This is a Foo object with value x: ${foo.x}`; 
   }

   const foo = {x: 1}; 
   expect(stringifyFoo(foo)).toBe("This is a Foo object with value x: 1");

In the scenario where the stringifyFoo method is only intended to be used with objects that fit Foo's shape, in the least, by adding those functions to the object means that your IDE is going to be helpful in telling you those methods straight away.

My question is - how well explored is this concept - does it have a different name?

What advantage would function programming have over this?

What do you call the style of monorepo that Babel and Material-UI use?

David Johnston — Fri, 27 Mar 2020 00:32:38 +0000

Both Babel and Material-UI are lerna monorepos.

They both have something in common where they install a lot of common dev dependencies at the project root - jest, babel, eslint etc.

Material-UI does a thing, where a given package's build scripts reference build scripts and configs at the project root:

    "build": "yarn build:cjs && yarn build:esm && yarn build:es && yarn build:umd && yarn build:copy-files",
    "build:cjs": "cross-env NODE_ENV=production BABEL_ENV=cjs babel --config-file ../../babel.config.js ./src --out-dir ./build --ignore \"**/*.test.js\"",
    "build:esm": "cross-env NODE_ENV=production BABEL_ENV=esm babel --config-file ../../babel.config.js ./src --out-dir ./build/esm --ignore \"**/*.test.js\"",
    "build:es": "cross-env NODE_ENV=production BABEL_ENV=es babel --config-file ../../babel.config.js ./src --out-dir ./build/es --ignore \"**/*.test.js\"",
    "build:umd": "cross-env BABEL_ENV=production-umd rollup -c scripts/rollup.config.js",
    "build:copy-files": "node ../../scripts/copy-files.js",
    "prebuild": "rimraf build",
    "release": "yarn build && npm publish build --tag latest",
    "test": "cd ../../ && cross-env NODE_ENV=test mocha 'packages/material-ui/**/*.test.js' --exclude '**/node_modules/**'",

Babel's packages don't even have build scripts, instead they are built via make files at the project root.

Additionally, both are using yarn, which has its own concept of workspaces.

What I'm wondering is how this fits in with monorepo design in general.

For example it makes sense that you would want a consistent code style across all of your monorepo, so eslint defined in the root makes sense.

However, in the case that your monorepo is a 'frontend/backend/common' type project - there are going to be linting rules (eg. React specific) that only apply to frontend, so this isn't necessarily always going to work. (I suppose you could have two different eslint configs in the root).

I think I've had a fundamental misunderstanding about monorepos - I had thought that basically each package in a monorepo should stand in its own right - that is, you should be able to checkout the project and build and test just the one package.

The idea being, that a project may have different teams, different ways of working, and so working on one package shouldn't require knowledge about how the other package works. However, the packages to have dependencies on each other, and you want that to 'just work' in development, which is where I've found lerna helpful.

This certainly isn't really the case with Babel - there are no build scripts in the packages, and at the project root just a single 'build' script. You would have to be diving into the make files to be building an individual package.

Can someone outline some of the key concepts people use to think about monorepos?

eg.

Common tooling at project root
What a standard 'getting started' flow looks like for a developer freshly checking out the project is.
What a standard build pipeline flow looks like. (My understanding for example just force publishes all packages, regardless of changes, and keeps all their versions in sync like that).

What do you call modern (frontend?) dependency architecture?

David Johnston — Thu, 12 Mar 2020 23:24:14 +0000

If I google 'dependency architecture' I get a bunch of results like this one, which has either this circle model:

Or this n-tier layered one. (To be fair, the source of this image is criticising this approach for not supporting dependency injection).

It seems to me that these diagrams are more relevant to conventional monoliths, where you seperate out your data access logic, your application logic, your frontend logic.

However, I'm thinking about in the context of microservices, and modern SPAs where there's a lot more logic happening on the frontend.

This talk by Monica Lent, where she's talking specifically about frontend architecture is what I have in mind.

Any suggestions, new key words to google? Or is the onion/n-tier architecture just are relevant to microservices and SPAs?