colinhacks

import { typeDefs as prismaSchema } from './client/prisma-schema';

const prismaAST = gql`
  ${prismaSchema}
`;

/* 
remove the built-in Mutation and Query objects
from the Prisma Client schema 
*/

colinhacks

SELECT DISTINCT "distinctAlias"."user_id" AS "ids_User_id" 
FROM   (SELECT "user"."id"                                              AS 
               "User_id", 
               "user"."createdat"                                       AS 
                      "User_createdAt", 
               "user"."updatedat"                                       AS 
                      "User_updatedAt", 
               "user"."authid"                                          AS 
                      "User_authId", 
               "user"."firstname"                                       AS 

colinhacks

const schema = yup.object({
  asdf: yup.string(),
});
schema.validate({}); // passes

type SchemaType = yup.InferType<typeof schema>;
// returns { asdf: string }
// should be { asdf?: string }

colinhacks

const numList = yup
  .array()
  .of(yup.string())
  .required();

// interpreted as a non-empty list
numList.validateSync([]); // fails

// yet the inferred type doesn't reflect this
type NumList = yup.InferType<typeof numList>;

colinhacks

const A = t.type({
  foo: t.string,
});

const B = t.partial({
  bar: t.number,
});

const C = t.intersection([A, B]);

colinhacks

type Primitive = string | number | boolean | null | undefined;
type Compound<U extends Primitive = Primitive> =
  | U
  | { [name: string]: Compound<U> }
  | []
  | [Compound<U>]
  | [Compound<U>, ...Compound<U>[]];
type Json<U extends Primitive> = U | Compound<U>;

// this function infers the EXACT type of the value passed into it

colinhacks

Achieving the Holy Grail of TypeScript Data Modeling Or, a scalable solution to type complexity

For the highly abbreviated version of this, check out this comment: colinhacks/zod#53 (comment). That comment conveys why this is so exciting. If you agree then the outline below explains the context for why I think it’s so exciting and introduces a the architectural concept of “ground truthiness” which I think is a very powerful notion.

Context

This journey started in 2018 when I decided to start a company. For inexplicable reasons I decided to build an electronic medical record software, one of the most regulated and complex product categories in the world. Also I was a solo founder. Now if you’re ever tempted to do this, for the love of god, don’t. Just say no!

Since this was medical software so I wanted it to be rock solid — end to end typesafety, powerful and expressive endpoints, painless schema migration. I was deeply entrenched in vanilla JavaScript development,

colinhacks

type GlobalCtx = {
  session: {
    authorize(): void;
  };
};

type LoginInputType = {
  email: string;
};

colinhacks

Emotion is my favorite CSS-in-JS library.

It's easy to define style classes (both inline or in separate files), compose them in powerful ways with the cx utility, sprinkle them into React components using the standard className attribute. There's no need to ever modify your markup/JSX to apply styles (as it should be!). Plus you only need to install a single module (yarn add emotion) and there's no complicated Babel plugin or config file to set up.

I'm currently building a Tailwind-style CSS-in-JS utility styling library (join my newsletter at the bottom of this page to stay updated!) and Emotion provides the perfect layer of abstraction to build upon.

Why @emotion/core is bad

Unfortunately everything I just said only applies to the vanilla emotion module (https://emotion.sh/docs/emotion), not the inexplicably-named @emotion/core module. @emotion/core is the React-focused Emotion wrapper that gives you some extra goodies, like server-side rendering and theming.

colinhacks

type Generics = Partial<{
  asdf:string;
  qwer : number;
}>

type Defaults = Required<{
  asdf: 'default';
  qwer: 1234;
}>;