JulianG

package
{  
  /**
	 * ObjectPool Class
	 * @author Julian
	 */
	public class ObjectPool
	{
		private var _list:Array;
		

JulianG

/*
tslint:disable no-any
tslint:disable no-empty
*/

class MutedConsole implements Console {

	memory: any;
	Console: NodeJS.ConsoleConstructor;
	assert(test?: boolean, message?: string, ...optionalParams: any[]): void { }

JulianG

Keybase proof

I hereby claim:

• I am juliang on github.
• I am juliang (https://keybase.io/juliang) on keybase.
• I have a public key ASC6w3PW2ig7pBT3EOlvCiqZnC4W60rPOG57MHiE4C807wo

To claim this, I am signing this object:

JulianG

Avoiding Non-null-assertion Operator in React + Mobx + Typescript Projects

Today I learned something at work. I am new to MobX and I had to make changes to a React + Typescript + MobX project. I noticed the props of some React components were marked as optional, and I was told it was because of how the dependency injection worked.

The Problem

When injecting MobX stores into React components in Typescript, the recommended approach in MobX docs involves declaring optional props (?). This results in having to perform null checks when accessing an injected store, and MobX recommendeds using the non-null assertion operator (!).

interface BananaProps {

JulianG

Null Checking in TypeScript

Following up on the previous gist about avoiding non-null-assertion operator I think it would be good to see some examples of null checking in TypeScript.

Assumming we're using TypeScript with --strictNullChecks, and that this is what a banana looks like:

type Banana = {
  id: number,
  open: () => void
};

JulianG

Introducing Banana Tabs!

Has this ever happened to you?

You keep lots of tabs in a single window to the point where you can't tell what's what anymore.

Or worse: you try -like me- to group your tabs by task, or subject, or anything, and as a result you end up with too many windows instead:

JulianG

Testing Opinions

⚠️ Warning! This article is highly opinionated.

It happens often at work that my colleagues and I discuss the best way or the proper way to test a specific React component. We don't always agree.

Testing the output of a function is not the same as testing its implementation details.

Avoid Testing Implementation Details

JulianG

DON'T DO THIS!

When working on legacy projects it may be tempting to go around changing

const myCopy = arr.slice();

with:

JulianG

Catching bugs with stricter TypeScript

We recently enabled "noImplicitAny" in a relatively old TypeScript project. It resulted in 269 new errors. Most of those were missing type annotations but in a few cases, we found problems with the code. These had been around for months and were not caught by our test suite.

TL;DR;

We should prefer strict TypeScript configurations to catch issues, not just at compile-time, but (with a good IDE) as we type.

We should try to keep up-to-date with TypeScript versions to benefit from the ever-improving error messages; saving development time.

JulianG

A use case for TypeScript Generics

The following may be a bit obvious for some. But something just clicked in my head and I thought I'd write it down.

When generics are a good idea

Imagine we write a function that returns the "oldest" item in a set/array:

function getOldest(items: Array<{ age: number }>) {