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

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

  // Available variables:
  // - Machine
  // - interpret
  // - assign
  // - send
  // - sendParent
  // - spawn
  // - raise
  // - actions

JulianG

// Daily Challenge #107 - Escape the Mines

// A poor miner is trapped in a mine and you have to help him to get out!
// The mine is completely dark so you have to tell him where to go.

// https://dev.to/thepracticaldev/daily-challenge-107-escape-the-mines-2036

// Based on: https://www.redblobgames.com/pathfinding/a-star/introduction.html
// by @redblobgames