
![A curious Panda](panda.png)

Like any decent tech that will significantly improve your life for the better, TypeScript will slow you down at first. I remember my frustration in the beginning; most of it was related to my little experience with how things should be typed in React.

In this article, I will save you some time (and nerves) by showing you how to type some of the most common React patterns.

## React onClick handler

How to correctly type an onClick handler?

Suppose you have a button or a regular link with an onClick handler attached to it.

```tsx
const handleClick = (event) => {
    event.preventDefault();
    // clicked
}

return (
    <a
        href="#"
        onClick={handleClick}
    >Click me</a>
);
```

Here, `event` is of type `any`. Instead, we can type the `event` parameter with `React.MouseEvent`.

```tsx
const handleClick = (event: React.MouseEvent) => {
    event.gTpreventDefault();
}
```

Or even better, we can type the handler itself.

```tsx
const handleClick: React.MouseEventHandler<HTMLAnchorElement> = (event) => {
    event.preventDefault();
};
```

In this case, the type of `event` is inferred automatically.

There are more handler types in React, like `TouchEventHandler`, `KeyboardEventHandler`, etc. Many of those can be used with multiple DOM events. For example, `MouseEventHandler` can be used for `onMouseUp`, `onMouseMove`, etc.

## onSubmit handler

It is similarly easy to type a form handler.

```tsx

const handleSubmit(e: React.FormEventHandler<HTMLFormElement>) {
    e.preventDefault()
}

return (
    <form onSubmit={handleSubmit}>
        <input type="text" placeholder="Name" />
    </form>
);
```

## Typing a React component

The easiest way to type a React component is to use `React.FC`. 

```tsx
const MyComponent: React.FC<{ title: string }> = ({ title }) => {
  return <h1>{title}</h1>;
};

```

The `FC` type (of course, short for "functional component") takes a parameter - the properties your component accepts.

Sometimes, it looks nicer if you put properties separately.

```tsx

type Props = {
    title: string
}

const MyComponent: React.FC<Props> = ({ title }) => {
  return <h1>{title}</h1>;
};

```

## Proper typing of useState hook

The [useState](https://react.dev/reference/react/useState) hook is trivial to type in cases where its type can be inferred from the default value.

```tsx
const [count, setCount] = useState(0);
// count is inferred to be number
```

Sometimes, however, the type cannot be inferred. For example, when the default value is `null`, or an empty array.

In this case, we type the hook explicitly.

```tsx
const [users, setUsers] = useState<User[]>([]);
```

## React type for useRef

The [useRef](https://react.dev/reference/react/useRef) hook has a wide range of applications. I use it most often to access DOM elements for some direct manipulation.

We want to ensure our `ref.current` is correctly typed. All we need to do here is to use a type parameter.

```tsx
const MyComponent = () => {
    const ref = useRef<HTMLDivElement>();

    useEffect(() => {
        if (!ref.current) {
            return;
        }

        // everyone loves aquamarine
        ref.current.style.color = 'aquamarine'
    }, []);

    return (
        <div ref={ref}>
            Hello
        </div>
    );
};
```

## Custom hooks

Custom hooks shouldn't need any special treatment. Just type them as you would type any other function.

## Typing a React Context

React context is a great way to pass data down the component tree. Typing it is more complex but still not too complicated.

A common way to use context is to create a context object and then use it to create a Provider and a hook to access the context.

```tsx
type Value = {
    theme: string
}

const defaultValue: Value = {
    theme: 'default'
}

const ThemeContext = createContext<Value>(defaultValue);

export const ThemeProvider: React.FC = ({ children }) => {
    const [theme, setTheme] = useState(defaultValue.theme);

    return (
        <ThemeContext.Provider value={{ theme }}>
            {children}
        </ThemeContext.Provider>
    );
};

export const useTheme = () => useContext(ThemeContext);
```

That's all we need to do. Here `type Value` is the single source of truth. React ensures that whenever we use `useTheme` hook anywhere in our app, the returning value is correctly typed (is `Value`).

Note that `ThemeProvider` can become however complex, but we will always be sure that the value we pass to the context is of the type `Value`.


## What's next

Well, I hope I saved you some time with this quick article.

If you want to dive deeper, here are some links you might enjoy:

- [Using TypeScript at React Docs](https://react.dev/learn/typescript)
- [Nice article from LogRocket on why and how](https://blog.logrocket.com/how-to-use-typescript-react-tutorial-examples/)
- [React + Typescript cheatsheets](https://github.com/typescript-cheatsheets/react)


How to type React components and hooks to make your life easier and your code more robust.

TypeScript and React common patterns


A [PubSub](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern) is an object that can subscribe to listeners and emit events.

One of the many possible interfaces can look like this.

```typescript
const pubsub = createPubSub()

pubsub.on("MY_EVENT", () => {
  console.log("Hello, pubsub!")
})

pubsub.emit("MY_EVENT");
// => Hello, pubsub!
```

Events might also go with some payload specific to the event type.

For example,

```typescript
pubsub.on("USER_LOGGED_IN", (name: string) => {
  console.log(`Hello, ${name}!`)
})
```

## First attempt

Let's first implement a first naive version with no types.

```typescript
function createPubSub() {
  const eventMap = {} as Record<"string", Set<(...args: any[]) => void>>;

  return {
    on: (event: string, callback: (...args: any[]) => void) => {
      if (!eventMap[event]) {
        // create a new set
        eventMap[event] = new Set();
      }

      eventMap[event].add(callback);
    },

    off: (event: string, callback: (...args: any[]) => void) => {
      if (!eventMap[event]) {
        return;
      }

      eventMap[event].delete(callback);
    },

    emit: (event: string, ...args: any[]) => {
      if (!eventMap[event]) {
        return;
      }

      eventMap[event].forEach((cb: any) => cb(...args));
    },
  };
}
```

Note we are using [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) for callbacks so we don't have to deal with duplicates.

While this works, it's not ideal. The most obvious problem is that we can easily emit events that don't exist.

## Typing events

Consider the following type:

```typescript
// no error
pubsub.on("USER_SIGND_IN", (name: string) => {
  console.log("...")
})

pubsub.emit("USER_SIGNED_IN", "john22@example.com")
```

How to make TypeScript help us here?

We can define a set of possible events upfront using [string type union](https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html).

```typescript
function createPubSub<T extends string>() {
  const eventMap = {} as Record<T, Set<(...args: any[]) => void>>;

  return {
    on: (event: T, callback: (...args: any[]) => void) => {
      if (!eventMap[event]) {
        // create a new set
        eventMap[event] = new Set();
      }

      eventMap[event].add(callback);
    },

    off: (event: T, callback: (...args: any[]) => void) => {
      if (!eventMap[event]) {
        return;
      }

      eventMap[event].delete(callback);
    },

    emit: (event: T, ...args: any[]) => {
      if (!eventMap[event]) {
        return;
      }

      eventMap[event].forEach((cb: any) => cb(...args));
    },
  };
}
```

We replaced the event `string` type with a more specific `T extends string`. Now when we create a pub-sub we can specify the event type.

```typescript
const pubsub = createPubSub<'USER_SIGNED_IN' | 'USER_LOGGED_OUT'>()

pubsub.on("USER_SIGND_IN", (name: string) => {
  console.log("...")
})
// (!) Argument of type '"USER_LOGGD_IN"' is not assignable to
// (!) parameter of type '"USER_LOGGED_IN" | "USER_SIGNED_OUT"'
```

Much better! TypeScript saved us a lot of time debugging a weird issue in runtime.

## Typing callbacks

Our events are typed now. But our callbacks are not.

Even though the emitted event goes with its own set of parameters, nothing prevents us from using it with a wrong callback.

```typescript
// USER_SIGNED_IN goes with an email
pubsub.emit("USER_SIGNED_IN", "john22@example.com");
pubsub.on("USER_SIGNED_IN", (id: number) => {
  // shouldn't work: event goes with email, not id
});

// USER_LOGGED_OUT goes without payload
pubsub.emit("USER_LOGGED_OUT");
pubsub.on("USER_LOGGED_OUT", (email: string) => {
  // shouldn't work: no payload with this event at all
});
```

Since each event is uniquely associated with a parameter list, we can solve it by making our `T` type a record.

```typescript
function createPubSub<T extends Record<string, (...args: any[]) => void>>() {
  const eventMap = {} as Record<keyof T, Set<(...args: any[]) => void>>;

  return {
    emit: <K extends keyof T>(event: K, ...args: Parameters<T[K]>) => {
      (eventMap[event] ?? []).forEach((cb) => cb(...args));
    },

    on: <K extends keyof T>(event: K, callback: T[K]) => {
      if (!eventMap[event]) {
        eventMap[event] = new Set();
      }

      eventMap[event].add(callback);
    },

    off: <K extends keyof T>(event: K, callback: T[K]) => {
      if (!eventMap[event]) {
        return;
      }

      eventMap[event].delete(callback);
    },
  };
}
```

It's a bit intense so let's first see how to use it, and then we'll explain how it works.

Now we can easily specify callback types.

```typescript
const pubSub = createPubSub<{
  USER_SIGNED_IN: (email: string) => void;
  USER_LOGGED_OUT: () => void;
}>();

pubSub.on("USER_SIGNED_IN", (id: number) => {
  // ...
})
// (!) Type 'string' is not assignable to type 'number'

pubSub.on("USER_LOGGED_OUT", (email: string) => {
  // ...
}
// (!) Argument of type '(email: string) => void' is not
// (!) assignable to parameter of type '() => void'.
```

And even on the emitter side, we are covered.

```typescript
pubSub.emit("USER_SIGNED_IN", 123)
// (!) Argument of type 'number' is not assignable
// (!) to parameter of type 'string'.
```

OK, now let's take a closer look at the `emit` declaration again:

```typescript
emit: <K extends keyof T>(event: K, ...args: Parameters<T[K]>) => {
    (eventMap[event] ?? []).forEach((cb) => cb(...args));
},
```

Assuming the `T` type is:

```typescript
{
  USER_SIGNED_IN: (email: string) => void;
  USER_LOGGED_OUT: () => void;
}
```

`keyof T` gives us `'USER_SIGNED_IN' | 'USER_LOGGED_OUT'` - pretty much the same type we used for events in the previous version.

Then `K extends keyof T` means that K is either `'USER_SIGNED_IN'` or `'USER_LOGGED_OUT'`.

Next, we specify parameters typed as `...args: Parameters<T[K]>`.

`T[K]` gives us the callback type associated with this event.

[Parameters](https://www.typescriptlang.org/docs/handbook/utility-types.html#parameterstype) is one of the handy built-in utility types. It takes a function and returns the type of parameters.

Hope it's clear now how it ensures the type safety both for events and the callbacks.


In this article, we create a simple PubSub (or event emitter) from scratch in TypeScript, and make it as type-safe as possible.

Let's build a Pub-Sub in TypeScript


In this article, we will build and publish an NPM package from scratch using TypeScript and Jest for testing.

We will initiate the project, set up TypeScript, write tests with Jest, and publish it to NPM.

## Our project

Our simple library is called `digx`. It allows "digging" values from nested objects by path (it's similar to [lodash get](https://lodash.com/docs/4.17.15#get)).

For example,

```javascript
const source = { my: { nested: [1, 2, 3] } }
digx(source, "my.nested[1]") //=> 2
```

For the sake of this article, it's not that important what it does as long as it's simple and testable.

The npm module [can be found here](https://www.npmjs.com/package/digx). The GitHub [repository is here](https://github.com/hiquest/digx).

## Initiate the project

Let's start by creating an empty directory and initiating it.

```bash
mkdir digx
cd digx
npm init --yes
```

The `npm init --yes` command will create a `package.json` file for you and fill it with some defaults (which you might want to update).

And let's also set up a git repo in the same folder.

```bash
git init
echo "node_modules" >> .gitignore
echo "dist" >> .gitignore
git add .
git commit -m "initial"
```

## Building the library

We will be using TypeScript. Let's install it.

```bash
npm i -D typescript
```

Let's create a `tsconfig.json` file with the following configuration:

```javascript
{
  "files": ["src/index.ts"],
  "compilerOptions": {
    "target": "es2015",
    "module": "es2015",
    "declaration": true,
    "outDir": "./dist",
    "noEmit": false,
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictBindCallApply": true,
    "strictPropertyInitialization": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noPropertyAccessFromIndexSignature": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true
  }
}
```

The most important settings are these:

1. Our main file is going to live in the `src` folder, hence `"files": ["src/index.ts"]`
2. `"target": "es2015"` to make sure we support modern platforms and don't carry around unnecessary shims
3. `"module": "es2015"`. Our module will be a standard `EC` module (the default is `CommonJS`). Modern browsers have no problems with them; even Node has supported them since version 13.
4. `"declaration": true` - because we want to emit the `d.ts` declaration files. Our TypeScript users will require those.

Most of the other stuff is just various optional TypeScript checks, which I prefer to be turned on.

Open the `package.json`, and update the "scripts" section:

```javascript
"scripts": {
  "build": "tsc"
}
```

Now we can run the build with `npm run build`... Which fails because we don't have any code to build yet.

But we will start from the other end.

## Adding some tests

As responsible grown-ups, we are going to start with the tests. We will use `jest` because it's simple and awesome.

```bash
npm i -D jest @types/jest ts-jest
```

The `ts-jest` package is required for Jest to understand TypeScript. An alternative is to use `babel`, which will require more configuration and additional modules. We'll keep things simple.

Init the jest configuration file with

```bash
./node_modules/.bin/jest --init
```

Just press enter on each question. Defaults are fine.

It will create the `jest.config.js` file with some defaults and add the `"test": "jest"` script into `package.json`.

Open the `jest.config.js`, find the line starting with `preset`, and update it like this:

```javascript
{
  // ...
  preset: "ts-jest",
  // ...
}
```

Finally, create the `src` directory and our test file `src/digx.test.ts` and fill it:

```javascript
import dg from "./index";

test("works with a shallow object", () => {
  expect(dg({ param: 1 }, "param")).toBe(1);
});

test("works with a shallow array", () => {
  expect(dg([1, 2, 3], "[2]")).toBe(3);
});

test("works with a shallow array when shouldThrow is true", () => {
  expect(dg([1, 2, 3], "[2]", true)).toBe(3);
});

test("works with a nested object", () => {
  const source = { param: [{}, { test: "A" }] };
  expect(dg(source, "param[1].test")).toBe("A");
});

test("returns undefined when source is null", () => {
  expect(dg(null, "param[1].test")).toBeUndefined();
});

test("returns undefined when path is wrong", () => {
  expect(dg({ param: [] }, "param[1].test")).toBeUndefined();
});

test("throws an exception when path is wrong and shouldThrow is true", () => {
  expect(() => dg({ param: [] }, "param[1].test", true)).toThrow();
});

test("works tranparently with Sets and Maps", () => {
  const source = new Map([
    ["param", new Set()],
    ["innerSet", new Set([new Map(), new Map([["innerKey", "value"]])])],
  ]);
  expect(dg(source, "innerSet[1].innerKey")).toBe("value");
});
```

Those unit tests give a good idea of what we are building. 

Our module exports a single function, `digx`. It accepts any object, the string `path` parameter, and an optional `shouldThrow`, which makes it throw an exception in case the nested structure of the source object doesn't allow the provided path.

The nested structures can be objects and arrays, but also Maps and Sets.

Run the tests with `npm t`; of course, they fail, as they should.

Now open the `src/index.ts` file and copy there:

```typescript
export default dig;

/**
 * A dig function that takes any object with a nested structure and a path,
 * and returns the value under that path or undefined when no value is found.
 *
 * @param {any}     source - A nested objects.
 * @param {string}  path - A path string, for example `my[1].test.field`
 * @param {boolean} [shouldThrow=false] - Optionally throw an exception when nothing found
 *
 */
function dig(source: any, path: string, shouldThrow: boolean = false) {
  if (source === null || source === undefined) {
    return undefined;
  }

  // split path: "param[3].test" => ["param", 3, "test"]
  const parts = splitPath(path);

  return parts.reduce((acc, el) => {
    if (acc === undefined) {
      if (shouldThrow) {
        throw new Error(`Could not dig the value using path: ${path}`);
      } else {
        return undefined;
      }
    }

    if (isNum(el)) {
      // array getter [3]
      const arrIndex = parseInt(el);
      if (acc instanceof Set) {
        return Array.from(acc)[arrIndex];
      } else {
        return acc[arrIndex];
      }
    } else {
      // object getter
      if (acc instanceof Map) {
        return acc.get(el);
      } else {
        return acc[el];
      }
    }
  }, source);
}

const ALL_DIGITS_REGEX = /^\d+$/;

function isNum(str: string) {
  return str.match(ALL_DIGITS_REGEX);
}

const PATH_SPLIT_REGEX = /\.|\]|\[/;

function splitPath(str: string) {
  return (
    str
      .split(PATH_SPLIT_REGEX)
      // remove empty strings
      .filter((x) => !!x)
  );
}
```

This implementation could be better, but what is important for us is that the tests are passing now. Try it yourself with `npm t`.

Now, if we run `npm run build`, we should see the `dist` directory with two files, `index.js` and `index.d.ts`.

Now we are ready to publish.

## Publishing the npm package

[Sign up at npm](https://www.npmjs.com/signup) if you haven't yet.

Then log in through your terminal with `npm login`.

We are just a step away from publishing our shiny new package. Still, there are a couple of things to take care of.

First, let's ensure we have the correct metadata in our `package.json`.

1. Make sure the `main` property is set to our built file `"main": "dist/index.js"`.
2. Add the `"types": "dist/index.d.ts"` for our TypeScript users.
3. Because our library is going to be used as an ESM module, we also need to specify `"type": "module"`.
4. The name and description should be filled in as well.

Next, we should take care of the files we're willing to publish. I don't feel like publishing any config files nor the source and test files.

One thing we could do is to use the `.npmignore` and list all the files we DON'T want to publish. I'd much prefer to have a "white list" instead - so let's use the `files` field in the `package.json` to specify the files we WANT to include.

```javascript
{
  // ...
  "files": ["dist", "LICENSE", "README.md", "package.json"],
  // ...
}
```

Finally, we are ready to publish our package.

Run,

```javascript
npm publish --dry-run
```

And make sure only the required files are included.

When we are ready, we can finally run,

```javascript
npm publish
```

## Testing it out

Let's create an entirely new project and install our module.

```bash
npm install --save digx
```

And now, let's write a simple program to test it out.

```javascript
import dg from "digx"

console.log(dg({ test: [1, 2, 3] }, "test[0]"))
```

Those are our types, that's nice!

![DIGX types are available out-of-the-box](digx_autocomplete.png)

Now run it with `node index.js`, and you should see `1` printed on the screen.

## Conclusion

We created and published a simple npm package from scratch.

Our library provides an ESM module, types for TypeScript, and is covered with tests using `jest`.

You would probably agree that it wasn't too hard.


In this article, we will develop and publish an NPM package from scratch using TypeScript and Jest for testing.

How to build, test, and publish a TypeScript npm package in 2022


Rails 7 has been released recently, introducing quite a significant front-end mechanics revamp. Webpacker has been retired, and DHH now makes [many compelling arguments](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755) in favor of a no-Node approach.

Well, maybe it'll get us somewhere someday, but at the moment, almost all of us prefer our TypeScript and/or JSX compiled to continue delivering quality stuff.

If you're not ready to embark on this delightful "no-transpiling" journey quite yet, there's a plan B.

In this article, we'll discuss how to set up Rails 7 for TypeScript and React, and we'll use the magnificent [esbuild](https://esbuild.github.io/) builder for that (Yay!).

## Installation

The good news is that esbuild does all the heavy lifting for us. TypeScript and JSX are supported out of the box. All we need to do is employ the [jsbundling-rails](https://github.com/rails/jsbundling-rails) gem.

We can install it along with a new rails app (using the `-j esbuild` flag), or if upgrading:

1. By adding `jsbundling-rails` gem in Gemfile and running `bundle install`
2. And then running `./bin/rails javascript:install:esbuild`

The last command will install esbuild, and add this command into `package.json`:

```
// package.json
"scripts": {
  "build": "esbuild app/javascript/application.tsx --bundle --sourcemap --outdir=app/assets/builds"
}
```

It's very straightforward. It takes the files from the `app/javascript` directory and then compiles them into `app/assets/builds` where they get picked up by [the asset pipeline](https://guides.rubyonrails.org/asset_pipeline.html).

There's also the `Procfile.dev` file, which is used to run several commands at once (using [foreman](https://github.com/ddollar/foreman)). Just remember to start your app with `./bin/dev` instead of the `./bin/rails server`. It will run both rails server and the esbuild.

Now rename `application.js` into `application.tsx`, put some JSX into it, and you're done.

```typescript
// app/javascript/entrypoint.tsx
import * as React from 'react'
import * as ReactDOM from 'react-dom'

const App = () => {
  return (<div>Hello, Rails 7!</div>)
}

document.addEventListener('DOMContentLoaded', () => {
  const rootEl = document.getElementById('app')
  ReactDOM.render(<AppWithState />, rootEl)
})
```

Include the file into the view with `javascript_include_tag 'application'` (no more `javascript_pack_tag`!).

Super-simple, and it's also super fast thanks to esbuild.

## Getting TypeScript errors

`esbuild` compiling is unbelievably fast, but it doesn't do any type-checking. We can still run it separately from the command line with something along these lines:

```bash
tsc --project tsconfig.json --noEmit
```

I prefer adding that into `project.json` script and into the `Procfile.dev` file.

```
// package.json
"scripts": {
  "build": "esbuild app/javascript/application.tsx --bundle --sourcemap --outdir=app/assets/builds"
  "check-types": "tsc --project tsconfig.json --noEmit --watch --preserveWatchOutput"
}
```

Note the last flag `--preserveWatchOutput`. It prevents `tsc` from automatically clearing the screen and blowing up the whole foreman output.

Then add it to the `Procfile.dev`:

```
types: yarn ts-check
```

## Next steps

This setup is what works for me at the moment. I imagine, in the meantime, more tools and gems emerge, providing better Rails integration, but so far, I'm pretty pleased with the ability to use esbuild.

This setup is what works for me right now. I imagine, in the meantime more tools and gems emerge providing better Rails intergration, but so far I'm pretty pleased with ability to use esbuild.

1. [Read this blog post](https://www.colby.so/posts/live-reloading-with-esbuild-and-rails) for live-reloading.

2. [Rails 7 introduction](https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision)

3. [A visionary post by DHH](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755)


Rails 7 is released, and now we can use esbuild to compile both TypeScript and JSX and enjoy the almost magical compilation speed.