Zod: The Next Biggest thing after Typescript

Oh, is that legal now?

Frankly, I don't know. That would require browsers to parse TypeScript, no? As TS is a proprietary language (Microsoft), I'm not really in favor of that.

What I am in favor of is TC-39 getting off their collective asses and implementing a decent, optional Hindley-Milner sort of type system with inferencing in the language. It could be a simple as a specific type of comment. For example, why not:

//+ string -> string -> string
function concatenate (left, right) {
  return left + right
}

This keeps the code itself very clean (TS types can make code very difficult to read). It also allows me to curry the function:

//+ string -> string -> string
function concatenate (left, right) {
  function concatTo(right) {
    return left + right
  }

  return arguments[1] == null ?  concatTo : concatTo(right)
}

concatenate("rama", "lama")            // "ramalama"
concatenate("ding", "dong")            // "dingdong"

const concatToJoe = concatenate("joe") // concatTo
concatToJoe(" mama")                   // "joe mama"

I don't need to type the inner function because it is inferred from the outer one. This seems very clean and workable to me, and any smart type system designer could come up with a good one in a month or two. So why the hell is it taking YEARS to get here? Simple answer: politics.

I don't see any reason why you can't type variables the same way, preferably with better types than JS currently has!

//+ int32
const usPopulation = 334_274_321

//+ uuid
const id = Crypto.randomUUID()

This is much less cognitive load than the current TS approach. Initially, int32 and uuid could be cast to number or bigint internally until runtimes could add the appropriate types. Of course, if BigInt is anything to go by, that will probably be around 2050 or so...

Smart editors, such as VSCode, should have a simple toggle for comments that allows you to toggle them on and off. And/or for types -- that's needed for TS right now! Why can't I hide them when I'm not needing them so I can focus on the algorithm itself without all the type noise, toggling them back on when I need to check the type (or seeing the type on hover)?

I have built multiple validation systems, including a few that use composition and a JSON configuration to build validators from potentially deeply nested validations. Here is an example from one I built last year:

import makeOperator from '../../../../makeOperator'
import type {
    AfterAlphabeticallyConstraint,
    Validation,
} from '../../../../types/constraints'
import { Operation } from '../../../../types/operations'
import type { StringValue } from '../../../../types/values'
import localeCompareSupportsLocales from '../../../utilities/localCompareSupportsLocales'
import makeError from '../../../utilities/makeError'

export default function makeAfterAlphabetically(
    constraint: AfterAlphabeticallyConstraint,
): (validation: Validation) => Validation {
    const { operand } = constraint
    const injector = (operand as Operation).operatorType
        ? makeOperator(operand as Operation)
        : () => operand

    return function afterAlphabetically(validation: Validation): Validation {
        const { language = 'en', options } = constraint

        const injected = injector()
        const testValue =
            typeof injected === 'string' ? injected : (injected as StringValue).value

        /* istanbul ignore next */
        const order = localeCompareSupportsLocales()
            ? ((testValue as string) || '').localeCompare(
                    validation.value as string,
                    language,
                    options,
              )
            : ((testValue as string) || '').localeCompare(validation.value as string)

        return order < 0
            ? validation
            : makeError(
                    validation,
                    constraint,
                    `come after ${testValue} alphabetically`,
              )
    }
}

(That's beta code, so no promises.)

You call makeAfterAlphabetically with the string that you want to test your input against. For example:

export type AfterAlphabeticallyConstraint = {
  readonly constraintType: TypeOfConstraint.AFTER_ALPHABETICALLY
  operand: Operation | StringValue | string
} & LocaleCompareOptions

const afterPearAlphabetically = makeAfterAlphabetically({
  constraintType: TypeOfConstraint.AFTER_ALPHABETICALLY,
  operand: "pear"
})

afterPearAlphabetically({
  datatype: "string",
  value: "pumpkin",
})

The call to afterPearAlphabetically above does not error, so it returns the Validation unchanged: { datatype: "string", value: "pumpkin" }. (constraintType is used to choose this function, but it passed because it appears in the error, below.)

But if I call it with "peach", I get an error:

{
  datatype: "string",
  errors: [
    constraint: {
      constraintType: TypeOfConstraint.AFTER_ALPHABETICALLY,
      operand: "pear"
    },
    error: "AFTER_ALPHABETICALLY_ERROR",
    errors: [],
  ],
  isInvalid: true,
  value: "peach",
}

This acts a bit like a monad. You can pass it from validator to validator and it will add the errors to the errors array (note that they can be nested as well, which is later flat mapped). There are also AND and OR validators, so I can do something like this in my configuration:

const constraint = {
  constraintType: TypeOfConstraint.AND,
  tests: [
    {
      constraintType: TypeOfConstraint.IS_INTEGER,
    },
    {
      constraintType: TypeOfConstraint.OR,
      tests: [
        {
          constraintType: TypeOfConstraint.AND,
          tests: [
            {
              constraintType: TypeOfConstraint.AT_LEAST_N,
              operand: 7,
            },
            {
              constraintType: TypeOfConstraint.LESS_THAN_N,
              operand: 11,
            },
          ],
        },
        {
          constraintType: TypeOfConstraint.AND,
          tests: [
            {
              constraintType: TypeOfConstraint.MORE_THAN_N,
              operand: 21,
            },
            {
              constraintType: TypeOfConstraint.AT_MOST_N,
              operand: 42,
            },
          ],
        },
      ],
    },
  ],
}

The above creates a single validate function that checks that the value to be tested meets:

(value >= 7 && value < 11) || (value > 21 && value <= 42)

These can be infinitely nested (but why?). I included static type checking, which allowed me to extend the type system to include integers, fractions, etc. Here's a list, to give an idea of the power of this approach:

• alphabetical
  • makeAfterAlphabetically
  • makeBeforeAlphabetically
  • makeNotAfterAlphabetically
  • makeNotAfterAlphabetically
• composers
  • makeAnd
  • makeOr
  • makeXor
• date
  • makeAfterDate
  • makeBeforeDate
  • makeOnOrAfterDate
  • makeOnOrBeforeDate
• datetime
  • makeAfterDateTime
  • makeBeforeDateTime
• length
  • makeAtLeastNCharacters
  • makeAtMostNCharacters
  • makeAtExactlyNCharacters
  • makeFewerThanNCharacters
  • makeMoreThanNCharacters
• number
  • makeAtLeastN
  • makeAtMostN
  • makeEqualToN
  • makeLessThanN
  • makeMoreThanN
  • makeNotEqualToN
• other
  • makeConfirmation
  • makeMatch
• sequence
  • makeIsOrderedList
  • makeIsReversedList
• set
  • makeIsDisjointWith
  • makeIsMemberOf
  • makeOverlapsWith
  • makeIsSubsetOf
  • makeIsSupersetOf
• static (I use Temporal)
  • makeIsArray
  • makeIsBoolean
  • makeIsDate
  • makeIsDateTime
  • makeIsDuration
  • makeIsFraction
  • makeIsInstant
  • makeIsInteger
  • makeIsList
  • makeIsMap
  • makeIsMember
  • makeIsMonthDay
  • makeIsPrecision
  • makeIsReal
  • makeIsSet
  • makeIsString
  • makeIsTimeZone
  • makeIsYearMonth
  • makeIsZonedDateTime

This was all part of a larger rendering system which essentially took a JSON object representing the DOM to be created, and then recursed through it to render the HTML elements, including form components. This part of a simple data-driven UI concept -- the GraphQL response builds the UI and the front end code is generic and small (can be statically-generated , too, of course). Simpler than React (and faster).

The "validators" are really just operators and can be combined with operators such as makeDivide (division) and makeEven (check input is an even number). And formatters such as makeAsCurrency or makeAsCreditCardNumber (which can themselves validate).

These can be used not only for form validation, but for conditional display of any part of the UI. Whole sections of pages can be conditionally displayed based on a boolean expression of any complexity. And the values used can be injected from anywhere -- the URL, session storage, a fetch call, another form field, whatever -- at compile time, at render, or even at runtime. Operands can themselves be operations, so you can nest.

This is a purely FP, immutable, composable approach. Some thinking remains about security -- this works as essentially a big eval function, so must think it through more. Also, need some way to tree shake so unneeded functions aren't loaded unnecessarily.

Obviously, there is too much here to give this a full explanation (if anyone has read this far). I built this for a company as a proof of concept, but it was just too much for the other devs and I think they abandoned it after my contract ended. Meanwhile I got interested in using a triple store and an ontology instead of a JSON config to generate the application, front and back, and am now (very slowly) working on that.

But a whole lot of that code could be avoided if a) JS had decent types, and b) JS had a solid, optional, runtime type checker with inferencing.

But I'm not expert on type systems so maybe there's something I'm missing.