JulianG

import React from 'react';

export function createStrictContext(options = {}) {
    const Context = React.createContext(undefined);
    Context.displayName = options.name;
    function useContext() {
        const context = React.useContext(Context);
        if (!context) {
            throw new Error(options.errorMessage || `${name || ''} Context Provider is missing`);
        }

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

JulianG

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

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 }>) {

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

DON'T DO THIS!

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

const myCopy = arr.slice();

with:

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

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

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
};