DEV Community: jarvispact

How to write your own zod

jarvispact — Tue, 21 Mar 2023 09:35:39 +0000

Intro

zod is a schema based validation library with static type inference. It is production ready, has a rich community and ecosystem. You should check it out if you have the need for such a library.

My approach to learn advanced typescript concepts was to create a similar library from scratch. If you are curious, you can check it out here: @jarvistack/nope. But today's blog post is not about my library. Instead i want to explain to you how it works under the hood and how you can create something similar yourself and learn something new while doing so.

Intro
Prerequisites
The basic idea
Some utilities
The validation function
The extendValidation function
The schema function
Opaque ( branded ) types
The InferType and InferErrorType helper
Closing

Prerequisites

Since this is a advanced typescript topic, i will assume that you are already familiar with:

Union types
Generics
Type predicates

If you are not, i suggest to you another blog post where i talk a bit about type inference, union types and generics. For type predicates i can recommend this blog post.

The basic Idea

With a union type we can represent that a variable is Either this or that. In other terms we might say a validation was Ok or it failed with an Err. This is how we can express this with a typescript type:

type Ok<T> = { status: 'OK'; value: T };
type Err<T> = { status: 'ERR'; value: T };
type Either<S, F> = Ok<S> | Err<F>;

With generics we can define a clear contract on how our schema needs to be defined and at the same time, leverage typescripts type inference and save the user of the library from having to define types themselves.
Type predicates are just functions that return a boolean. We can define even the most complex validation logic in such a function, and by adding a type predicate to this function we can tell typescript that we made sure that some variable of type Input is of a certain Output type. This is a simple string type predicate function:

// `unknown` is our `Input` type
// `string` is our `Output` type
const isString = (input: unknown): input is string => typeof input === 'string';

const someInput = 42 as unknown;

if (isString(someInput)) {
    // in here `someInput` is of type `Output` (`string`)
} else {
    // in here `someInput` is still of type `Input` (`unknown`)
}

Now we have all the ingedients to write the most awesome validation library of all time. The goals for our validation library are:

Awesome DX: Users of the library write no types themselves.
Typesafety: The static type is inferred correctly for success and error case.
Runtime safety: The value at runtime matches our validation logic.

Some utilities

Lets start by defining some utils:

// We know that already :)
type Ok<T> = { status: 'OK'; value: T };
type Err<T> = { status: 'ERR'; value: T };
type Either<S, F> = Ok<S> | Err<F>;

// helpers to create the above types
const err = <T>(value: T): Err<T> => ({ status: 'ERR', value });
const ok = <T>(value: T): Ok<T> => ({ status: 'OK', value });

// helpers to check if a value is `Ok` or an `Err`
const isErr = <O, E>(either: Either<O, E>): either is Err<E> => either.status === 'ERR';
const isOk = <O, E>(either: Either<O, E>): either is Ok<O> => either.status === 'OK';

// helper to create a validation error
type SchemaError<Code extends string = string> = { code: Code };
const createError = <Code extends string>(code: Code): SchemaError<Code> => ({ code });

With that in place, we can move on and create a validation() function to define a clear constract and to help us create new validations.

The validation function

type Validation<Input, Output extends Input, Err extends SchemaError> = {
    // the `is` function needs to be a type predicate, which will check our input data at runtime
    is: (input: Input) => input is Output;
    // the `err` function defines how to create a error object.
    // if the `is` function returns false, we will call it
    err: (input: Input) => Err;
};

// we just return the input argument, without doing anything to it
// this allows us to leverage typescript type inference
// and reduce the number of types our library user has to write
const validation = <Input, Output extends Input, Err extends SchemaError>(validation: Validation<Input, Output, Err>) =>
    validation;

With this function we are now able to define a StringValidation with just 4 lines of code:

const StringValidation = validation({
    is: (input): input is string => typeof input === 'string',
    err: () => createError('E_STRING'),
});

To create a EmailValidation we can already reuse our StringValidation and with just 7 lines of code we are done:

const EmailValidation = validation({
    is: (input): input is string => StringValidation.is(input) && input.includes('@'),
    err: (input) => {
        if (!StringValidation.is(input)) return StringValidation.err(input);
        return createError('E_EMAIL');
    },
});

Even this code could be further reduced by writing a little helper function, called extendValidation().

The extendValidation function

This one has quite complex generic types. But other than the types, there isnt a lot going on in the code. You could build the validation library also without this function. Its really just for convenience. The simple version without generic types looks like this:

const extendValidation = (wrappedValidation: Validation) => (newValidation: Validation) => ({
    is: (input) => wrappedValidation.is(input) && newValidation.is(input),
    err: (input) => {
        if (!wrappedValidation.is(input)) return wrappedValidation.err(input);
        return newValidation.err(input);
    },
})

Click here to see it with generic types, if you dare 😈

With that in place we can define validations like a IntegerValidation, UnsignedIntegerValidation, UuidValidation and many many more validations that build upon a string or number. Look how simple it is now to define the EmailValidation:

const EmailValidation = extendValidation(StringValidation)({
    is: (input): input is string => input.includes('@'),
    err: () => createError('E_EMAIL'),
});

Awesome 🤩! 2/3 of the work is done with just 2 functions. Now we will take a look on what is missing.

The schema function

type SchemaArgs<Input, Output extends Input, Err extends SchemaError> = {
    create: (input: Input) => Output;
    validation: Validation<Input, Output, Err>;
};

type Schema<Input, Output extends Input, Err extends SchemaError> = {
    create: (input: Input) => Output;
    validate: (input: Input) => Either<Output, Err>;
};

// the `create` function is needed to convert a `Input` to a `Output` type. This will be very handy later on...
// the `validate` function just wraps validations as we know them already inside of the `Either<Ok, Err>` type

const schema = <Input, Output extends Input, Err extends SchemaError>({
    create,
    validation,
}: SchemaArgs<Input, Output, Err>): Schema<Input, Output, Err> => ({
    create,
    validate: (input: Input) => (validation.is(input) ? ok(create(input)) : err(validation.err(input))),
});

Let me show you now the complete code that's necessary to define a StringSchema and how to use it:

// definition

const StringValidation = validation({
    is: (input): input is string => typeof input === 'string',
    err: () => createError('E_STRING'),
});

const StringSchema = schema({
    create: (input) => String(input),
    validation: StringValidation,
});

// usage

const either = StringSchema.validate(42);
if (isOk(either)) {
    const aString = either.value; // typeof `aString`: string
} else {
    const errCode = either.value.code; // typeof `errCode`: "E_STRING"
}

The exact same concept applies for a EmailSchema:

// definition

const EmailValidation = extendValidation(StringValidation)({
    is: (input): input is string => input.includes('@'),
    err: () => createError('E_EMAIL'),
});

const EmailSchema = schema({
    create: (input) => String(input),
    validation: EmailValidation,
});

// usage

const either = EmailSchema.validate(42);
if (isOk(either)) {
    const aString = either.value; // typeof `aString`: string
} else {
    const errCode = either.value.code; // typeof `errCode`: "E_STRING" | "E_EMAIL"
}

As you can see, defining a new type is just a couple lines of code.

Opaque ( branded ) types

NOTE: This is completely optional! Skip this section if you want to have a email address typed as string in your system. But we can have a stricter Email type that gives us some compile time guarantees if we want! Curious?

Opaque types are not available in typescript out of the box, but we can make it work with a simple trick:

// helper type (just needed once)

declare const tag: unique symbol;

type Tagged<Token> = {
    readonly [tag]: Token;
};

type Opaque<Type, Token = unknown> = Type & Tagged<Token>;

// definition of our more strict `string` and `number` types.

type Email = Opaque<string, 'Email'>;
type UnsignedInteger = Opaque<number, 'UnsignedInteger'>;

The Email type is still assignable to a string, but not vice versa. Also the UnsignedInteger type is still assignable to a number, but not vice versa. Typescript autocompletion is still available for string and number functions. All of the following code compiles just fine:

const email = 'tony@starkindustries.com' as Email;
const lowercaseEmail = email.toLowerCase(); // ok

const sendEmail = (emailAddress: string) => {};
sendEmail(email); // ok
sendEmail(''); // ok

const lengthOfSomeList = 1 as UnsignedInteger;
const timesTen = lengthOfSomeList * 10; // ok

const getElementFromList = (list: number[], index: number) => {};
getElementFromList([], lengthOfSomeList); // ok
getElementFromList([], -1); // ok

But if we define a opaque type for a function argument, we cannot pass simple strings or numbers anymore:

const email = 'tony@starkindustries.com' as Email;

const sendEmail = (emailAddress: Email) => {};
sendEmail(email); // ok
sendEmail(''); // Argument of type 'string' is not assignable to parameter of type 'Email'

const lengthOfSomeList = 1 as UnsignedInteger;

const getElementFromList = (list: number[], index: UnsignedInteger) => {};
getElementFromList([], lengthOfSomeList); // ok
getElementFromList([], -1); // Argument of type 'number' is not assignable to parameter of type 'UnsignedInteger'

This lets us define a more concrete / strict type, which leads to a safer codebase. This is how we would define a EmailSchema with a branded type and how we can use it:

// definition

type Email = Opaque<string, 'Email'>;

const EmailValidation = extendValidation(StringValidation)({
    is: (input): input is Email => input.includes('@'),
    err: () => createError('E_EMAIL'),
});

const EmailSchema = schema({
    create: (input: string) => input as Email,
    validation: EmailValidation,
});

// usage

const either = EmailSchema.validate('tony@starkindustries.com');
if (isOk(either)) {
    const aEmail = either.value; // typeof `aEmail`: Email
} else {
    const errCode = either.value.code; // typeof `errCode`: "E_STRING" | "E_EMAIL"
}

Before, i told you that the create function will be handy later on. We are using it here to create the type Email from a string. The create function itself does not guarantee that the variable holds a correct value at runtime, but when we use the EmailSchema.validate() function, and we check if the validation was ok with the isOk() function, we can be sure that:

the value is of type Email
and that a variable holds the correct value at runtime

If the validation failed (the else branch of the example above) you will have strongly typed error objects. Every possible error that can happen gets its own type as defined by our validations. The validation() and schema() functions in this blog post are kept simple to outline the basic principle to you.

Also the examples of a StringSchema and a EmailSchema are quite simple. It starts to get more complex when you want to have a ArraySchema that wraps some schema for its items, or a ObjectSchema that wraps a object where every value in that object is another schema. But in my library @jarvistack/nope i have proven that this abstraction of a validation() and a schema() function holds. Even for quite complex wrappers. You can get some inspiration on how to build those wrapper schemas from my repository. Let me know in the comments if you want another blog post which shows how to create a ArraySchema or ObjectSchema in detail.

The InferType and InferErrorType helper

We can now write little helper types, that will extract the static types from any schema, no matter how complex or deep. Just like you know it from zod:

export type InferType<S extends Schema<string, any, SchemaError>> = ReturnType<
  S['validate']
> extends Either<infer O, unknown>
  ? O
  : never;

export type InferErrorType<S extends Schema<string, any, any, SchemaError<string>>> = ReturnType<
    S['validate']
> extends Either<any, infer E>
    ? E
    : never;

And use it to extract the output and error types from the schema:

type Email = InferType<typeof EmailSchema>;
type EmailError = InferErrorType<typeof EmailSchema>; // "E_STRING" | "E_EMAIL"

Closing

We learned today:

How to create a validation and schema function to build all sorts of different schemas like a
- StringSchema
- NumberSchema
- EmailSchema
- UnsignedIntegerSchema.
How to infer the static types for the Ok and every possible Err case of all sorts of schemas.
How to define opaque (branded) types and schemas to make our domain types more strict and avoid even more bugs at compile time.

Here is a interactive example for this blog post where you can see the actual output in the browser and play around with the input data. I hope that you learned something new, or that i inspired you to dig a bit deeper into this topic yourself. Also i would be very happy about feedback and suggestions to improve my writing skills.

Happy type-safety!👋.

Typescript - beyond the basics

jarvispact — Mon, 27 Dec 2021 18:09:29 +0000

Intro

This blog post is for you if you have found yourself like this

This is not a Getting Started Tutorial. I will not cover the absolute basics or type annotations with types like string, number, boolean, Array or Record. I assume that you worked with typescript in the past. This blog post starts with a brief explanation of the following concepts:

type inference
intersection and union types
keywords: typeof, keyof and as const
type narrowing

and then goes a bit deeper into the more advanced topics like:

generics
fixing Object.keys
writing a typesafe omit function

Typescript is awesome, but i have seen many repositories which dont really use, but abuse typescript. I hope that you can leverage the knowledge from this blog post to refactor some of your existing typescript code and:

catch some bugs at build time
benefit from better intellisense
and write lesser types by using the type inference from typescript

Ok. Let's start!

Type inference

Here is an example of the type inference from typescript when declaring an array:

const array = [1, '42', null]; // typeof array: (string | number | null)[]
const item = array[0]; // typeof item: string | number | null
array.push(true); // Argument of type 'true' is not assignable to parameter of type 'string | number | null'

// ---

// you can use a type annotation to also support "boolean" values
const array: (string | number | null | boolean)[] = [1, '42', null];
array.push(true); // ok

Another example with objects:

const obj = { a: 'a', b: 'b' }; // typeof obj: { a: string; b: string; }
// obj.c = 'c'; // Property 'c' does not exist on type '{ a: string; b: string; }'

// ---

// you can use a type annotation to also support other string keys than "a" and "b"
const obj: { [Key: string]: string } = { a: 'a', b: 'b' };
obj.c = 'c'; // ok

What is also very interesting is the difference between let and const:

let aLetString = 'test'; // type: string
const aConstString = 'test'; // type: "test"

let aLetNumber = 1; // type: number
const aConstNumber = 1; // type: 1

const takeString = (x: string) => x;
const result = takeString(aConstString); // typeof result: string

Have you noticed that we have passed something of type: "test" to our takeString function? The function accepts a argument of type string, but lets us pass something of type: "test" without any error. Heres why:

A string literal type can be considered a subtype of the string type. This means that a string literal type is assignable to a plain string, but not vice-versa.

Examples alway makes it more clear:

const B = 'B'; // typeof B: "B"
type A = string;
const test: A = B; // ok

// ---

type A = 'A';
const test: A = 'B'; // Type '"B"' is not assignable to type '"A"'

Intersection and Union types

Here an example of the & (intersection) and | (union) operators:

type Intersection = { a: string } & { b: number };
const test1: Intersection = { a: 'a', b: 1 }; // ok
const test2: Intersection = { a: 'a' }; // Property 'b' is missing in type '{ a: string; }' but required in type '{ b: number; }'

// ---

type Union = { a: string } | { a: number };
const test1: Union = { a: 'a' }; // ok
const test2: Union = { a: 1 }; // ok

There is a difference in type and interface for object types. You cannot use the & and | operators with interfaces, but you can with types. Personally i always use types because they have no limitations. However you can use the extends keyword, or use a type to make a union of 2 existing interfaces:

interface A { a: string }
interface B extends A { b: number }
const test1: B = { a: 'a', b: 1 }; // ok
const test2: B = { a: 'a' }; // Property 'b' is missing in type '{ a: string; }' but required in type 'B'

// ---

interface A { a: string }
interface B { a: number }
type Union = A | B;
const test1: Union = { a: 'a' }; // ok
const test2: Union = { a: 1 }; // ok

The keywords: `typeof`, `keyof` and `as const`

Maybe you have seen or used the types typeof and keyof before. as const seems to be not used a lot in the wild, but i like it a lot.

const obj = { a: 'a', b: 'b' };
type Obj = typeof obj; // { a: string; b: string; }

// ---

const obj = { a: 'a', b: 'b' };
type Key = keyof typeof obj; // "a" | "b"

// ---

const obj = { a: 'a', b: 'b' } as const;
type Obj = typeof obj; // { readonly a: "a"; readonly b: "b"; }

As you can see, the keyword as const also sets the values of the object to string literal types ("a" and "b" instead of string). Lets have a closer look at the as const keyword and a potential use case to replace enums.

// https://www.typescriptlang.org/play?target=99&jsx=0#code/AQ4UwOwVwW2BhA9lCAXATgT2AbwFCiHACCAKgDQFEgAiAopdSPABKOgC+QA
enum Country {
    AT,
    DE,
    CH,
}

// gets compiled to:
let Country;
(function (Country) {
    Country[(Country['AT'] = 0)] = 'AT';
    Country[(Country['DE'] = 1)] = 'DE';
    Country[(Country['CH'] = 2)] = 'CH';
})(Country || (Country = {}));

If you log the value of Country.AT at runtime, you will see that the value of it is the number 0. I dont like enums that have a number as the value, because now you have this number in your database and without the enum definition in your code you are not able to tell what this number means. Enums that have string values are better imho, since they have a semantic meaning. There is another way to write a enum which uses string values:

// https://www.typescriptlang.org/play?target=99&jsx=0&ssl=5&ssc=6&pln=1&pc=1#code/AQ4UwOwVwW2BhA9lCAXATgT2AbwFCiHACCAKsALzABEZ1ANAUSACICilN7DTz8AEp2oCehAL5A
enum Country {
    AT = 'AT',
    DE = 'DE',
    CH = 'CH',
}

// gets compiled to:
var Country;
(function (Country) {
    Country["AT"] = "AT";
    Country["DE"] = "DE";
    Country["CH"] = "CH";
})(Country || (Country = {}));

So how can we use as const to write something like an enum?

const Country = {
    AT: 'AT',
    DE: 'DE',
    CH: 'CH',
} as const;

const values = Object.values(Country);
type Country = typeof values[number];

// gets compiled to:
const Country = {
    AT: 'AT',
    DE: 'DE',
    CH: 'CH',
};

I leave it up to you to decide which one you like better. In the end it doesnt matter, but i like the fact that you have immediate intellisense with the as const variant and dont need to import the enum on every place where you use this enum, but you still could if you prefer that.

enum Country {
    AT = 'AT',
    DE = 'DE',
    CH = 'CH',
}

// you always need to import the Country enum to use this function
const doSomethingWithEnum = (country: Country) => country;

doSomethingWithEnum(Country.AT); // ok
// doSomethingWithEnum('AT'); // Argument of type '"AT"' is not assignable to parameter of type 'Country'

// However doSomethingWithEnum('AT') would lead to working javascript code!


// ---

const Country = {
    AT: 'AT',
    DE: 'DE',
    CH: 'CH',
} as const;

const values = Object.values(Country);
type Country = typeof values[number];

// intellisense support and no need to import the country object to use this function
const doSomethingWithCountry = (country: Country) => country;

doSomethingWithCountry('AT'); // ok
doSomethingWithCountry(Country.AT); // ok
// doSomethingWithCountry('US') // Argument of type '"US"' is not assignable to parameter of type '"AT" | "DE" | "CH"'

Apart from the potential replacement of a enum, as const can be used for other things as well. I will show you another use case within the next section.

Type narrowing

Type narrowing can be used to accept different types in a function, but then safely narrow down the type and perform different actions for different types:

const format = (value: string | number) => {
    if (typeof value === 'string') {
        // value is of type string and all string functions are available within the if block
        return Number.parseFloat(value).toFixed(2);
    } else {
        // value is of type number and all number functions are available within the else block
        return value.toFixed(2);
    }
};

Typescript has really awesome type inference, which lets us narrow the type based on a type of a common property:

const a = { value: 'a' };
const b = { value: 42 };
type AOrB = typeof a | typeof b;

const takeAOrB = (aOrB: AOrB) => {
    if (typeof aOrB.value === 'string') {
        const { value } = aOrB; // typeof value: string
    } else {
        const { value } = aOrB; // typeof value: number
    }
};

But we can also narrow it if they have no common property, but 2 different proeprties:

const a = { a: 'a' };
const b = { b: 42 };
type AOrB = typeof a | typeof b;

const takeAOrB = (aOrB: AOrB) => {
    if ('a' in aOrB) {
        const { a } = aOrB; // typeof a: string
    } else {
        const { b } = aOrB; // typeof b: number
    }
};

At some point it becomes practical to introduce a kind or type property which then can be used to distinguish between different types (this kind property could also be used in a switch case):

const a = { kind: 'a' as const, value: 'a' };
const b = { kind: 'b' as const, value: 42 };
type AOrB = typeof a | typeof b;

const takeAOrB = (aOrB: AOrB) => {
    if (aOrB.kind === 'a') {
        const { value } = aOrB; // typeof value: string
    } else {
        const { value } = aOrB; // typeof value: number
    }
};

Ok, i think that one was pretty straightforward. Now lets dig into generics. I have used typescript a long time without ever writing a generic type myself. They may look scary, but trust me, as soon as you know how to use generics, it will open up a whole new world for you and unlock some really cool features :)

Generics

Generics can be hard to understand if you have never worked with a type system before, thats why i want to explain it in detail to you. Imagine you want to write some function that accepts any value as argument and passes it back as the return value. You would need to write a union of every possible type or use any. Both are not a good solution for it, since the return value will not have the proper type.

type Primitive = string | number | boolean;

const identity = (
    x: Primitive | Array<Primitive> | Record<string, Primitive>,
) => x;

const test1 = identity('a'); // typeof test1: Primitive | Primitive[] | Record<string, Primitive>
const test2 = identity(1); // typeof test2: Primitive | Primitive[] | Record<string, Primitive>

You would need to perform a type narrowing on the returned value in order to work with it in a type safe manner. any would save you from writing a union of every possible type, but leads or less to the same result:

const identity = (x: any) => x;
const test1 = identity('a'); // typeof test1: any
const test2 = identity(1); // typeof test2: any

Generics to the rescue!

const identity = <T>(x: T) => x;
const test1 = identity<string>('a'); // typeof test1: string
const test2 = identity<string>(1); // Argument of type 'number' is not assignable to parameter of type 'string'
const test3 = identity<number>(1); // typeof test3: number
const test4 = identity<boolean>(true); // typeof test4: boolean

Because it was hard for me to understand what happens here when i saw this syntax the first time, let me try to explain with my own words:

You want to write a util function that one of your co-workers can use and this function is the identity function in the examples above. There are 2 views on this:

You as the writer of the function
The user of this util function (your co-worker)

First you need to write this function, before your co-worker is able to use it. That means that at the time you write this function, you have no idea which type will be passed to this function by your co-worker. It could be anything 😉. The type is only known once the function is called with some argument. Your co-worker can even rely on the type inference from typescript and dont specify a type at all:

const identity = <T>(x: T) => x;
const test1 = identity('a'); // typeof test1: "a"
const test2 = identity(1); // typeof test2: 1
const test3 = identity(true); // typeof test3: true

This also leads to the positive side effect that we get even more concrete types. So:

"a" instead of string
1 instead of number
true instead of boolean

Awesome! You can also restrict the input via the extends keyword. Lets see 2 examples on how we could restrict the identity function to only accept a string or union type:

const identity = <T extends string>(x: T) => x;
const stringTest = identity('a'); // typeof stringTest: "a"
const numberTest = identity(1); // Argument of type 'number' is not assignable to parameter of type 'string'

// ---

const identity = <T extends 'A' | 'B' | 'C'>(x: T) => x;
const test1 = identity('A'); // typeof stringTest: "A"
const test2 = identity('D'); // Argument of type '"D"' is not assignable to parameter of type '"A" | "B" | "C"'

Now we are at a point where we can have a look at a real world example of a function with a generic argument and a constraint. This is a util function that i need in every project, and after the next section, you will probably also have one in every project from now on.

Fixing `Object.keys`

I dont know if you have noticed this already, but the builtin function to get the keys of an object (Object.keys) has not the correct typings. The problem:

const obj = { a: 'a', b: 'b' };
type Obj = typeof obj; // { a: string; b: string; }
type Key = keyof Obj; // "a" | "b"

const keys = Object.keys(obj); // typeof keys: string[]

I would expect the type of keys to be: ("a" | "b")[]. Typescript inferred a single key correctly: "a" | "b", but the type of the return value string[] of Object.keys seems wrong. Now that we know what the problem is, we can try to write our own wrapper function with proper typing:

const objectKeys = <T extends Record<string, unknown>>(obj: T) =>
    Object.keys(obj) as Array<keyof T>;

const obj = { a: 'a', b: 'b' };

const keys = objectKeys(obj); // typeof keys: ("a" | "b")[]
type Key = typeof keys[number]; // "a" | "b"

What happens here? We created a function that accepts a argument with an generic type, but we have restricted it to an object type. So typescript will complain if you try to pass a string or a Array as argument. Since typescript has really good type inference, it will know that only a and b are valid keys for this object and pass back this type to us: ("a" | "b")[]. If you would add a c key to the object, it will pass you back: ("a" | "b" | "c")[] without any changes on the implementation of the function and without writing a type yourself. Thats the power of generics. 😍

A type safe `omit` function

Lets do this in 4 iterations, going from an naive approach to a full typesafe approach. The logic for the omit function is the same in all 4 iterations. We will only change the types.

Naive

const omit = (obj: Record<string, unknown>, keysToOmit: Array<string>) =>
    Object.fromEntries(
        Object.entries(obj).filter(([k]) => !keysToOmit.includes(k)),
    ) as Record<string, unknown>;

const obj = { a: 'a', b: 'b' };

omit(obj, ['c', '42']); // ['c', '42'] is a valid argument, but it should not be valid!

const partialObj = omit(obj, ['a']); // typeof partialObj: Record<string, unknown>
const a = partialObj.a; // typeof a: unknown
const b = partialObj.b; // typeof b: unknown
const c = partialObj.c; // typeof c: unknown

In this approach we are not using generics. The only typescript support we have is that the first argument needs to be a object and the second should be a array of strings. The type of the return value is: Record<string, unknown> which basically means: some unknown object. a and b on the return type are typed as unknown. If we try to access c which was not even present on the input, we get unknown and no error. 😔

Typescript support for `keysToOmit`

const omit = <T extends Record<string, unknown>>(
    obj: T,
    keysToOmit: Array<keyof T>,
) =>
    Object.fromEntries(
        Object.entries(obj).filter(([k]) => !keysToOmit.includes(k)),
    ) as Record<string, unknown>;

const obj = { a: 'a', b: 'b' };

omit(obj, ['c']); // Type '"c"' is not assignable to type '"a" | "b"'

const partialObj = omit(obj, ['a']); // typeof partialObj: Record<string, unknown>
const a = partialObj.a; // typeof a: unknown
const b = partialObj.b; // typeof b: unknown
const c = partialObj.c; // typeof c: unknown

Now we are using generics and by doing so, we can provide the user of the function with some intellisense for the keysToOmit argument. But the type of the return value is still: Record<string, unknown>. Also we still get unknown for a, b and c. 😔

Typings for the return value

const omit = <T extends Record<string, unknown>>(
    obj: T,
    keysToOmit: Array<keyof T>,
) =>
    Object.fromEntries(
        Object.entries(obj).filter(([k]) => !keysToOmit.includes(k)),
    ) as Partial<T>;

const obj = { a: 'a', b: 'b' };

const partialObj = omit(obj, ['a']); // typeof partialObj: Partial<{a: string; b: string; }>
const a = partialObj.a; // typeof a: string | undefined
const b = partialObj.b; // typeof b: string | undefined
const c = partialObj.c; // Property 'c' does not exist on type 'Partial<{ a: string; b: string; }>'

We still have the improvements from the last iteration regarding the keysToOmit argument, but now also add as Partial<T> to the end of the omit function, which makes the type of the return value a little more accurate. a and b are typed with string | undefined which is somehow correct. But we now get a error when we try to access c. Still not perfect. 😔

Typesafe approach

const omit = <T extends Record<string, unknown>, K extends Array<keyof T>>(
    obj: T,
    keysToOmit: K,
) =>
    Object.fromEntries(
        Object.entries(obj).filter(([k]) => !keysToOmit.includes(k)),
    ) as Omit<T, K[number]>;

const obj = { a: 'a', b: 'b' };

const partialObj = omit(obj, ['a']); // typeof partialObj: Omit<{ a: string; b: string; }, "a">
const a = partialObj.a; // Property 'a' does not exist on type 'Omit<{ a: string; b: string; }, "a">'
const b = partialObj.b; // typeof b: string
const c = partialObj.c; // Property 'c' does not exist on type 'Omit<{ a: string; b: string; }, "a">'

Now look at this. It is wonderful! You have all the benefits of the previous iterations and also the type of the return value is now 100% correct. Only b is a valid key and it is typed as string which is also correct. Trying to access a on the return value will result in an error, because it was removed by our function. Trying to access c will also result in an error, since it was not even present on the input object. 😍

Closing

I hope you learned something new and i would be happy about feedback. Ok 👋

From Waiter to Developer

jarvispact — Sun, 08 Aug 2021 09:18:27 +0000

Hi 👋 My name is Wolfgang, on the internet i am @jarvispact. I live in Vienna, Austria and i work for a software development company as a Full-Stack Web Application Developer since 4 years now. I mostly create big multi-tenant web applications with React. Today i want to share with you the journey from being a waiter to my current job as a developer.

When i tell my journey to new co-workers, they always love my story, so i decided to share it with everyone. I hope that this story keeps you moving towards your goal when you have hard times. Maybe it even encourages somebody to also take such a journey to his dreamjob.

I dropped out of middle school and took an apprenticeship as a cook and waiter and worked in the gastronomy for about 10 years. It was fun. I worked on every weekend and on holidays. I used go through the nights and used to sleep until midday the next day. When i met my wife and had a serious relationship for the first time, i realized that i should change my life. I was 26 when i decided to do something else. but what? 🤔 I had no idea. I applied for some random jobs, most of the companies just ignored me. I had some interviews at companies with a pyramid scheme. I wasnt able to find anything reasonable and i was disappointed and lost my self-confidence. I have given up and kept working as a waiter.

One day i was talking with a regular guest of the beer pub i was working at this time. He was a 50 year old Cobol programmer. I was kinda interested in this weird magical craft of programming, but all i knew about computers at this time was how to look something up on the internet and how to play solitaire. When i asked him how i could try this out with a very simple programming language, he told me to have a look at Java. So i arrived home that day, looked a lot of youtube videos on how to install Java and the Eclipse IDE. I remember when i clicked Run for the first time and the console showed those famous 2 words: "Hello World". I think i spent an entire month by just trying to modify or extend those few lines of Java in every possible way. At some point i was able to receive an input from the console and react to the input in my program. I felt like Neo, now that all computers will bend to my will.

There was a entire universe to discover. It was a creative process of creation. You are creating things that were simply not there before. With a micro controller like arduino you can even create and program things that exist in real life. I was addicted. I tried every idea that came to my mind.

Since programming now was my new hobby, i wanted to also do this as my main job. So i was curious to see if i even have got talent for this or if i at least can do more that simple question-answer programs. I asked the regular guest from the beer pub for a little coding challenge. He told me to implement the Sierpinski’s triangle algorithm.

The algorithm:

Randomly place 3 points on the screen.
Pick a random location point on the plane to set as the current ‘focal point’
Select one of the 3 nodes at random
Compute & mark the half-way point (Euclidean distance) between the focal point & the selected node
Set the marked point as the new focal point
Repeat steps 3-to-5 many times (10'000+)

The problem was that i have never heard about recursion and i think that was also the first time in my life where i heard the term "algorithm" outside of a movie or tv series. It was way to early for me to tackle such a hard problem. I tried my best, but i was not able to solve it for months. I left it to do something else and came back to it more than once. In all those months i was sure, that i will never get a job as a programmer. I was disappointed again and lost all my self-confidence. However one day i got it right and this beautiful pattern arised in a java swing application. I was Neo again 😂. I proudly showed it to my regular guest after months of pain and struggle. He didnt even remembered that he told me to implement this algorithm, but i was sure that i want to do this as my main job, and that i will put in all of my spare time and energy to make this happen somehow.

A couple of months later i turned 27 and my son was born. That reduced my spare time drastically. I didnt wanted to put all of my spare time into learning something that may or may not work out for me. I kept learning, but i tried to do it when my son was sleeping. I wanted to do my high school degree and i wanted to study software engineering at a university afterwards, but i decided to stay autodidact, because that left me with more time for my son and it seemed that i can find everything on the internet that i need.

My progress really gained momentum, when i switched my waiter day job for a position as a support clerk at a webhoster and domain provider. Now i was in front of a computer all day and could use the time in my day job to lern even more, but this time about the terminal, ssh, docker, server administration and dns. I started to understand how the internet works and got in touch with ♥ javascript ♥. I left Java and started to write web applications with Node.js and Angular 1. I got in touch with the developers in this company and attended my first developer conference. I was a little misplaced, but i got introduced to a lot of new frameworks and libraries that i could look up and try out later. One of them beeing React. When i looked into React it just felt right from the very beginning for me. The Component model and the uni-directional data flow was a lot easier to grasp for me than this bi-directional data binding in angular with all those services and controllers.

From this moment on i focused on React and Node.js. Looking back now, it seems to be the best choice at the best time. This was around 2016. Around 2017 i felt ready to apply for jobs as a Frontend or Full-Stack Developer. I applied at a company who sponsored a meetup. They invited me to an interview. I went there without a cv, because all my previous jobs as a waiter wouldnt be interesting for them anyway. The only thing i took with me was my laptop. They were asking me some technical questions and i could answer the most of them. Also i showed them a project i was working on. The project was built with Node.js and React, had a little Frontend, a well tested backend and had a docker-compose.yml file to start it. This project wasnt even finished, it just had some basic views and forms that were connected to the api. The 2 weeks i had to wait for an answer from them, were the longest 2 weeks in my life. When they told me that i got the job i was like

That i got the job on the first try, surely involved a lot of luck as well, but i realized that i could have applied earlier already. I am a perfectionist and i wanted to do everything right on my first try. During my career as developer i met a lot of people that applied at this company with way less experience and some of them also got a job.

What i want to tell you with my story, is that you can apply at jobs way earlier than you might think. Dont let perfectionism get into your way. Sometimes it is enough to show a little proof that you know how to write a application with the tech stack that company is using.

Working at a software development company will make you learn a lot faster. When learing on your own in your spare time, you maybe have got 2 hours a day. In a company you got 8 hours a day and you even get paid for it. Also there are more experienced co-workers around you, that are willing to help you with your problems and will point you in the right direction when you are stuck.

Just dont give up and belive in yourself. If i can do it, you can do it!

DEV Community: jarvispact

How to write your own zod

Intro

Table of contents

Prerequisites

The basic Idea

Some utilities

The validation function

The extendValidation function

The schema function

Opaque ( branded ) types

The InferType and InferErrorType helper

Closing

Typescript - beyond the basics

Intro

Type inference

Intersection and Union types

The keywords: typeof, keyof and as const

Type narrowing

Generics

Fixing Object.keys

A type safe omit function

Naive

Typescript support for keysToOmit

Typings for the return value

Typesafe approach

Closing

From Waiter to Developer

The algorithm:

The keywords: `typeof`, `keyof` and `as const`

Fixing `Object.keys`

A type safe `omit` function

Typescript support for `keysToOmit`