Typescript can be really powerful way of enhancing your react components to ensure the correct props are provided with expected values. Sometimes however you may want some props to required based on what other props have been provided!

Let's dive into an example:

```jsx
const Image = ({ src, width, height, layout, ...rest }) => (
  <img
    src={src}
    width={width}
    height={height}
    className={`layout-${layout}`}
    {...rest}
  />
);
```

Now, our `layout` prop here might only be able to accept certain values. For example: `responsive` or `fill`. So let's convert this example into Typescript:

```tsx
import React, { FC } from 'react';

type Layout = 'responsive' | 'fill';

type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
  width: string | number;
  height: string | number;
  layout: Layout;
};

const Image: FC<ImageProps> = ({
  src, width, height, layout, ...rest
}) => (
  <img
    src={src}
    width={width}
    height={height}
    className={`layout-${layout}`}
    {...rest}
  />
);

export default Image;
```

So now we have correct typed the correct values, what if we wanted to enforce a rule that when `layout="fill"` is provided you are NOT allowed to define the `width` or `height` props. But when `layout="responsive"` is provided you MUST set them.

Well, to do that we can change our `ImageProps` type to support exactly this.

```ts
type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
} & ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
});
```

Let's break this down slightly:

Using the `Omit` utility type we are retrieving all the props that an `img` element can have, then omitting the `src`, `width` and `height` props. This allows us to redefine them in our type.

```ts
Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'>
```

Next up we define the `src` prop as a required string value. The `&` will merge this with the previous  type.

```ts
& {
  src: string;
}
```

Next up is where the magic happens. We're defining a conditional type, where we're saying that when `layout` is provided with the `'fill'` value it will use the first. Otherwise it'll use the second type.

The `Exclude` utility type is similar to `Omit`. 

```ts
& ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
})
```

Below is the completed example. You'll notice there is also the `toInt` function in order to catch when `width` or `height` is the `never` type instead of passing it directly into the `img` component. 

```tsx
import React, { FC } from 'react';

function toInt(value: unknown): number | undefined {
  if (typeof value === 'number') {
    return value;
  }

  if (typeof value === 'string') {
    return parseInt(value, 10);
  }

  return undefined;
}

type Layout = 'responsive' | 'fill';

type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
} & ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
});

const Image: FC<ImageProps> = ({
  src, width, height, layout, ...rest
}) => {
  const widthInt = toInt(width);
  const heightInt = toInt(height);
  return (
  <img
    src={src}
    width={widthInt}
    height={heightInt}
    className={`layout-${layout}`}
    {...rest}
  />);
}

export default Image;
```

I found this pattern whilst exploring NextJS' Image component: https://github.com/vercel/next.js/blob/canary/packages/next/client/image.tsx, I have attempted to simplify the example here for demonstration purposes.

In this post I also touched on Utility Types (`Exclude` and `Omit` specifically). If you'd like to learn more about them you can see the Typescript documentation: https://www.typescriptlang.org/docs/handbook/utility-types.html

Conditionally required props with Typescript in React

One of the things I like from other languages like PHP is how you can throw and catch specific exceptions. Replicating this in JS/TS however requires a little extra work.

Here's a PHP example for reference:

```php
<?php
class MyException extends Exception { }

function myFunction() {
  throw new MyException('some reason');
}

try {
  myFunction();
} catch (MyException $e) {
  // Handle MyException specifically...
} catch (Exception $e) {
  // Handle all other exceptions
}
```

Now over in JS/TS environments the `try/catch` block doesn't support handling different instances of errors. Instead we'd need to add `if`/`else` or `switch` conditions inside the body of the `catch` in order to handle different cases.

However, in Typescript you cannot simply extend `Error` and expect to be able to use: `if (error instanceof MyError) { }`... Since Typescript 2.1 extending built-ins like `Error`, `Array` and `Map` may not work as you'd expect.

The workaround for this is to call: `Object.setPrototypeOf(this, MyError.prototype)` from within your consructor. Like so:

```ts
class MyError extends Error {
  constructor(message: string) {
    super(message);
    Object.setPrototypeOf(this, MyError.prototype)
  }
}
```

Now the following code will work:

```ts
const myFunction = () => {
  throw new MyError('some reason');
}

try {
  myFunction();
} catch (error) {
  if (error instanceof MyError) {
    // Handle MyError....
  }
}
```

Previously you would have received an instance of `Error` instead of `MyError`.

This is due to how [Typescript handles generating the constructor](https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#generated-constructor-code-substitutes-the-return-value-of-super-calls-as-this).

This approach to handling errors can produce a bit of nesting in your `catch` block, however it allows to handle each error differently. I find this useful when you're handling multiple scenarios where an error could be thrown, in some instances you may wish to ignore it or hide it.

Consider the following:

```ts
import axios from 'axios';

class JSONAPIError extends Error {
  constructor(message: string) {
    super(message);
    Object.setPrototypeOf(this, MyError.prototype)
  }

  public static fromAxiosError(error: AxiosError) {
    // Surface the detailed error result from our JSON:API compliant api.
    // This error could be more useful to end users
    // Axios error.message contains the status and statusText which
    // isnt useful to users.
    return new JSONAPIError(error.response?.data?.errors[0].detail ?? error.message);
  }
}

const makeApiCall = async (method, url) => {
  try {
    const response = await axios.request({ method, url });
  } catch(error) {
    if (error.response.status === 500) {
      // Notify your error handling system.
      console.error(error);
      // Throw again with a bett
      throw new Error('Internal server error, please try again or contact support');
    }

    throw JSONAPIError.fromAxiosError(error);
  }
}

try {
  const result = await makeApiCall('GET', 'https://google.com/');
  return result;
} catch(error) {
  // A consistent API for handling errors with half decent messages 😍
  window.alert(error.message);
}

```

The above example shows us how we can better control error messages that could be displayed to an end user. Furthermore I'm still exposing the same API you'd expect from `Error`. Axios in this case adds the `response` property where we can access the response from the call that was made, if our code could throw two different errors we'd have the muddy our application logic with checks if certain properties exist. However, I've tucked this away within a function that can be used for making those api calls. Our client that is rendering the error only needs to care about accessing `error.message`. 

Typescript Posts

Conditionally required props with Typescript in React

Handling custom error classes in Typescript