DEV Community: Prithpal Sooriya

Advanced TypeScript - typing JSON/Resource files.

Prithpal Sooriya — Sat, 11 Sep 2021 22:11:16 +0000

By setting resolveJsonModule in your tsconfig to true, TypeScript will attempt to get the type/shape of the JSON for you.

We can use this to provide better type safety and auto complete for functions that use the JSON files.

For example typing i18n/resource. Either for custom solutions, library wrappers, or for libraries themselves.

Using existing/static imports.

Static imports are the usual imports you see at the top of the file.

If we are already statically importing our JSON resource, we can use typeof & keyof to get its type and keys.

import Resources from './resource.json';
type ResourceKeys = keyof typeof Resources;

// Index to keys path if complex.
// type ResourceKeys = keyof typeof Resources['path']['to']['key']

...

function translate(key: ResourceKeys): string { ... }

Using Dynacmic Imports

If we are worried about the import cost, then we can use dynamic imports for our actual code & type imports for the TypeScript types.

// Type only import.
// Stripped when transpiled
import type Resources from './resource.json';
type ResourceKeys = keyof typeof Resources;

async function connect(...) {
  // Dynamic import
  const resource = await import ('./resource.json');
  ...
}

...

function translate(key: ResourceKeys): string { ... }

If your version of TypeScript does not support typed imports, then we can extract out the types to separate file.

// ResourceTypes.ts
/*
  Import is only used for type (no JS code).
  This file only contains types.
  > Will get transpiled to an empty file
  > Will be tree shaken out of bundle.
*/
import Resources from './resource.json'
export type ResourceKeys = keyof typeof Resources

Using Declaration Files

Finally we could modify/use declaration files. This is great if you are using a library E.g. i18next docs.

Conclusion

We have successfully used this to provide auto-complete & type safety. We have even spotted missing or misspelled keys!

One caveat is that we had to restart our TS server if our resources were modified or new keys were added. I think this was due to our large resources, or maybe due to caching done on the TS server?

But a relatively small price to get this type safety.

How to Type React DefaultProps

Prithpal Sooriya — Thu, 22 Jul 2021 07:58:47 +0000

Situation/Background

We have inherited an old complex class-based component that took an array of items and rendered them.
It had a similar structure to this:

export interface ListProps {
  items: string[];
  filterPredicate?: (item: string) => boolean;
  onSelect?: (item: string) => void;
  onMultiSelect?: (items: string[]) => void;
  createKey?: (item: string, index: number) => string;
  // ... a lot of props
}
class List extends React.Component<ListProps> {
  static defaultProps: Partial<ListProps> = {
    // defaults for most props except `items`
    // because we want it will always be required right??
  };
}

This component was treated as an atomic component and, since it has stuck around for ~3 years, a lot of other components have used it to build their UI's.

This component did not lack tests, it was quite thoroughly tested. Again the test structure looked similar to this:

import { ListProps } from "./ListComponent";
// ...
const testProps: ListProps = {
  items: [
    /*...*/
  ],
  // ...
};
// Then some enzyme tests using props
// NOTE that all tests were strictly typed & used the exported ListProps type to create the test props

Back to the present

Some new logic was added to one of these components that inherited the List component.

Everything was working as expected until we hit our favourite runtime error:
Cannot read property 'length' of undefined

But why?? Everything was strictly typed, how did this fall through?

It turned out this new logic could potentially return an undefined list of items (string[] | undefined). But TypeScript should have picked this up when we used it as a prop for our List component, so why did we not get any errors about this?

Default Props and Merged Props.

The type ListProps for our component is NOT the true & final prop types when we are instantiating the new JSX List element. It merges the props we provide it at the start (the extends React.Component<ListProps>) with the typeof defaultProps.

Here it is in the DefinitelyTyped repo (see Defaultize type), but a simplified version is shown below:

// simplified version of the DefinitelyTyped - Defaultize utility
// Under the hood, the merge takes:
// - the default props (and makes them all optional),
// - and the remaining original props
MergeProps<Props, DefaultProps> =
  Partial<DefaultProps> &
  Omit<Props, keyof DefaultProps>

So what is the type of our default props? Thats right we strictly made it Partial!
So plugging this in the MergeProps utility, we can see it makes all of our props optional.

type FinalProps = MergeProps<ListProps, Partial<ListProps>>;
// this returns string | undefined! Proof that our items have become optional!
type Items = FinalProps["items"];

// Proof Identity - the above merged props is the same as Partial of all props.
// A = B -> true
type Identity1 = FinalProps extends Partial<ListProps> ? true : false;
// B = A -> true
type Identity2 = Partial<ListProps> extends FinalProps ? true : false;
// (A = B) & (B = A) -> true! It is identical.
type IdentityProof = Identity1 & Identity2;

So our final props are optional/Partial. You can even see the incorrect typings via IntelliSense:

This is also the reason why we didn't see this in our tests - we were relying too much on our exported ListProps type, when in actuality we should have tested with this merged type to cover these missed test cases!

Whats worse is that this pattern was used in a lot of other legacy class components.

What are we going to do 😬😬😬?

Fixing our Default Props!

We want our defaultProps to be strictly typed, it follows our developer standards & we want to have that wonderful IntelliSense, type safety & ability to easily refactor our props.

After some reading, one of the recommended ways of typing it is to split out our Large interface into smaller interfaces & merge them:

interface RawProps {
  items: string[]
}
interface DefaultProps {
  onSelect?: (item: string) => void
  //...
}
//...
static defaultProps: DefaultProps = {/* yay Typesafety, IntelliSense & Refactoring */}

However this wasn't really feasible for this old component - it already had a huge list of props & decoupling would have taken quite a lot of time (especially for all the other legacy components).

Instead we can Pick our default props, and using a utility, we can correctly infer our Pick type (instead of manually writing a large Pick) & still have our wonderful IntelliSense/Type Safety/Ability to Refactor.

// implicit pick utility
const buildImplicitPick =
  <T>() =>
  <K extends keyof T>(props: Partial<T> & Pick<T, K>): Pick<T, K> =>
    props;

const defaultListProps = buildImplicitPick<ListProps>();

//...
static defaultProps = defaultListProps({/* yay Typesafety, IntelliSense & Refactoring */})

Conclusion

TypeScript is super powerful and can resolve most mistakes that could appear are runtime right as your are typing - a very small feedback loop!
However bad types & relying too much on strict, predefined types can blindside us/introduce type holes where we lose our type safety.

It was understandable why this happened on these legacy components, since it was also our first time using TypeScript.
In the future we can mitigate the above by spending time to ensure that the type we get/want to use is correct & even introduce type tests to validate our types.

Now back to fixing these new TS errors 🙃.

Resources

CodeSandbox link to show the problems and solutions mentioned.
https://codesandbox.io/s/xenodochial-framework-tq7dx?file=/src/App.tsx
Link to my article that explains the type safe implicit pick utility.

How To Create a Type-Safe Implicit Pick

Prithpal Sooriya ・ Jun 29 ・ 4 min read

#typescript #productivity #showdev #developerexperience

How To Create a Type-Safe Implicit Pick

Prithpal Sooriya — Tue, 29 Jun 2021 21:43:53 +0000

This article discusses the implementation of an implicit pick, the reason for it & what makes it special.

Here is a Typescript Playground with examples that will be used as a reference. Can also be found via my Github Repo.

Prithpal-Sooriya / ts-implicit-pick

Example of an implicit pick.

Why an implicit Pick? Why not Partial?

Partial is great if you want to create an object with some of the values from a given interface. However when the object is used (via property access or through some consuming type), the object still is a Partial - as in all properties are optional, even if you have provided a value.

In these cases, what we really want is a Picked object - an object with the properties we want "picked" out of the original interface.

The Verbosity of Pick

Pick is perfect, it gives us the exact strict type that we want, however (as shown) it is very verbose.

For each prop we want, we need to write it for the type as well as for the object.
For small objects, this might not be much of an issue - however this can become very large the more props we want.

So now lets design an implicit pick!

1st Implicit Pick - Okay, But No IntelliSense 😢

Here is the design of the initial implicit Pick.

const buildImplicitPickVer1 =
  <T>() =>
  <K extends keyof T>(props: Pick<T, K>): Pick<T, K> =>
    props;

// Usage
const pickProduct = buildImplicitPickVer1<Product>();
const implicitProduct = pickProduct({ id: '1', ... })

Breakdown:

<T>() =>
- The is a factory function part that allows you to build a pick on whatever type you provide it.
<K extends keyof T>
- We have a generic type K that is constrained to the type given in the factory.
(props: Pick<T, K>): Pick<T, K>
- this parameter gets inferred as the developer types in the keys of their object.
- Invalid keys will give us an error (since does not match the Generic type)
- Invalid values for the key will give us an error, since it won't match the Picked object values.

This is exactly what we want - a type-safe implicit pick! Refactored changes (renaming/removing) on the interface will propagate through to the objects too!

Well... after some usage I found that it didn't really give a good Developer Experience (DX).

IntelliSense/auto-complete (via CTRL + SPACE) doesn't give us any useful information on what props we can use.

Only once we start typing do we get errors if a key does not match the interface, we aren't able to get a list of all keys that we can use.

This is because our parameter type in our factory function Pick<T, K> relies on keys given. Lets fix that!

Implicit Pick with Great Dev Experience!

Here is the the solution:

const buildImplicitPick =
  <T>() =>
  <K extends keyof T>(props: Partial<T> & Pick<T, K>): Pick<T, K> =>
    props;

The small change that made the huge difference is the intersection type Partial<T> & Pick<T, K>

The Partial<T> give us the ability to get back our auto complete for keys.
Intersecting is with the Pick & Pick<T, K> ensures that we get the correct type for our key.

Intersection above means that we take only the props/types that match in both types given.

type A = { a: number | undefined }
type B = { a: number }
type C = A & B; // will be { a: number } since that is what both types above have.

Whats awesome is that we can see the IntelliSense working in real time!
When we CTRL + SPACE to see what props are available, they are all optional because of the Partial.

But as soon as we select a property to use, it becomes required:

because the Generic K keys are updated;
subsequently so is the Pick<T, K>
and finally the intersection Partial<T> & Pick<T, K> enforces are type to be required.

Conclusion

Above shows how to write a type-safe, refactor-safe implicit Pick function with useful IntelliSense information.

The function itself is rather simple, but the main takeaway for me is to try/test out different type implementations to provide better IntelliSense information & better developer experience (DX).

FizzBuzz... but only using TypeScript Types

Prithpal Sooriya — Sun, 04 Apr 2021 14:57:26 +0000

Typescript 4.1 has released some awesome new features, including Template Literals - which enable some really powerful stuff!

To try it out, I've done the generic FizzBuzz test only using Typescript Types!

Prithpal-Sooriya / ts-fizz-buzz

The generic Fizz Buzz test built entirely with TypeScript type annotations.

ts-fizz-buzz

The generic Fizz Buzz test built entirely with TypeScript type annotations.
This means that is works solely on typescript types - so it is a compile time Fizz Buzz "Solution".
And using VSCode IntelliSense you see the solution without even "running" your code!

See a live demo

Playground Link

View on GitHub

This post is a breakdown/explanation of the types created & used in the Repo.

Outline & Plan.

FizzBuzz is a basic programming task that is (was?) used in interviews.
For those who've never seen the Fizz Buzz problem here it is:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Before we delve into the solution, I think its worth breaking down the tasks we need to accomplish:

Build our Predicate Types. We need a way to see if a number is divisible by 3 or 5.
Combine our Predicate Types & solve FizzBuzz for a single number.
Solve FizzBuzz for an array of numbers.

Predicate Types - check the divisibility

We want to check if a number is divisible by 3 or 5, but sadly TypeScript (currently) does not support arithmetic operations - e.g. we can't use a modulus to see if a number is divisible.

But TS Template Literals now allow us to build some of the divisibility rules!

// 5 Divisibility rule, we only need to look at last digit & see if it is a 0 or 5.
export type IsDivisibleBy5<T extends number> =
  `${T}` extends `${infer OtherDigits}${0 | 5}` ? true : false;

Breakdown:

<T extends number> - This enforces users to only input numbers.
`${T}` - The back ticks are the new template literal syntax, this allows us to convert the number input into a string.
`${infer OtherDigits}...` - the infer acts like a wildcard that is (in this case) a string without the final character.
`${0 | 5} ? true : false - checks if the last number is 0 or a 5. It if is, then the Type resolves to true otherwise false.

Sadly I couldn't generate the number 3 divisibility rule (since it includes adding each digit, which requires an arithmetic operation), so stuck with a simple union of valid numbers.

// Unsure if it is possible to generate a 3 Divisibility rule using current version of Typescript
type Finite3Tuple = [
  0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33,
  36, 39, 42, 45, 48, 51, 54, 57, 60, 63, 66,
  69, 72, 75, 78, 81, 84, 87, 90, 93, 96, 99
]
export type IsDivisibleBy3<T extends number> =
  T extends Finite3Tuple[number] ? true : false;

Fizz Buzz for a single number

// This is to remove the number at end of recursive concatenation in FizzBuzz below.
// E.g. Fizz4, Fizz2, ...
type RemoveTrailingNumber<Str extends string | number, T extends number> =
  `${Str}` extends `${infer Rest}${T}` ? Rest : Str

// Helper type to abstract the recursion & conversion
type ConcatBuzz<T extends number, BuzzPredicate> = RemoveTrailingNumber<FizzBuzz<T, null, BuzzPredicate>, T>

/* Fizz Buzz type used for single number */
export type FizzBuzz<
  T extends number,
  FizzPredicate = IsDivisibleBy3<T>,
  BuzzPredicate = IsDivisibleBy5<T>
> =
  FizzPredicate extends true ? `Fizz${ConcatBuzz<T, BuzzPredicate>}` :
  BuzzPredicate extends true ? `Buzz` :
  T

The idea behind it is that it will recursively build the FizzBuzz string. Whenever the Fizz is found, we can then combine the Buzz onto it (if found). To prevent the Fizz/Buzz from continuously being concatenated, we set their predicate to null.

Lets focus on the Main FizzBuzz type, the other types are just helpers to abstract out the recursion & trimming the output.

It takes 3 arguments/generics. T extends number which is the input; and the Fizz & Buzz Predicates (FizzPredicate & BuzzPredicate).
If FizzPredicate is valid, then we start building our string `Fizz${ConcatBuzz<T, BuzzPredicate>}`.
- The ConcatBuzz is just a helper type to abstract away the recursion. It recalls FizzBuzz, but sets the FizzPredicate to null, so the remaining iterations go through the rest of the predicates.
If BuzzPredicate is valid, then we just return Buzz.
Finally, if none of the predicates are valid then we just return the number.

Fizz Buzz for an array

type CalculateFizzBuzz<T extends number> = FizzBuzz<T, IsDivisibleBy3<T>, IsDivisibleBy5<T>>

export type FizzBuzzArray<Arr extends number[]> = {
  [K in keyof Arr]: CalculateFizzBuzz<Arr[K] & number>
}

CalculateFizzBuzz is just a helper type that allows us to simplify FizzBuzzArray type.

Breakdown of FizzBuzzArray:

Arr extends number[] - enforces that the type must take a number array. This will be our input.
{ [K in keyof Arr]: ... } - Arrays can be treated as objects where the keys are the indices. So we can use the keyof to go through each key/index.
CalculateFizzBuzz<Arr[K] & number> - This runs FizzBuzz for this value with the given index. The & number is the TS intersection type - we can use it to enforce that the given value is a number.
- Similarly, we could have used a ternary as well: Arr[K] extends number ? CalculateFizzBuzz<Arr[K]> : never

Thats it!
Now if we give it an input array, we get the FizzBuzz result out of it!

Check out the TS playground in the Github repo for more (& for an extended version of FizzBuzz).

DEV Community: Prithpal Sooriya

Advanced TypeScript - typing JSON/Resource files.

Using existing/static imports.

Using Dynacmic Imports

Using Declaration Files

Conclusion

How to Type React DefaultProps

Situation/Background

Back to the present

Default Props and Merged Props.

Fixing our Default Props!

Conclusion

Resources

How To Create a Type-Safe Implicit Pick

Prithpal Sooriya ・ Jun 29 ・ 4 min read

How To Create a Type-Safe Implicit Pick

Prithpal-Sooriya / ts-implicit-pick

Example of an implicit pick.

Why an implicit Pick? Why not Partial?

The Verbosity of Pick

1st Implicit Pick - Okay, But No IntelliSense 😢

Implicit Pick with Great Dev Experience!

Conclusion

FizzBuzz... but only using TypeScript Types

Prithpal-Sooriya / ts-fizz-buzz

The generic Fizz Buzz test built entirely with TypeScript type annotations.

ts-fizz-buzz

See a live demo

Outline & Plan.

Predicate Types - check the divisibility

Fizz Buzz for a single number

Fizz Buzz for an array