Type systems

Cool things I like

Why you want more type errors

How to get more type errors

Thinking with types

...beyond

More type errors!

What is a type?

a group of things that can be used interchangeably

What is a type?

• numbers (a * b, x - y)
• strings
• things that have a name attribute

JavaScript has a type system!

typeof x

What are type errors?

when you try to use a thing in a context where it doesn't work.

JavaScript has type errors!

but not nearly as many as one would want.

• _ is not a function
• cannot read property '_' of null/undefined

Either you get weird type errors late

  var x = 10
  var y = x.parent
  // ^ the real error is thinking `x` has a `.parent`
  return y.name
  // ^ but JS gives us the error here

...or no errors at all

function doSomething(m) {
  // numbers don't have a count
  if (m.count > 2) {
    return "large"
  } else {
    return "small"
  }
}
// but js will happily return "small" here
doSomething(5)

JavaScript tries to avoid errors

2/'' === Infinity
2 + {} === '2[object Object]'
2 + 'phone' -> NaN
alert(1, 2, 3, 4, 5)

but it backfires

How to get more type errors

• linters
• custom runtime checking
• static type checking

Linters

Linters know about 2 types

• declared
• not declared

function doSomething(argument) {
  return brgment + 1 // ERROR brgment is never declared
}

Linters

Custom runtime checking

Custom runtime checking

Sometimes useful, frequently annoying.

// `greet` takes 3 arguments:
// a string, a list, and a number

// Valid usage
greet("hello", ["June"], 10)
greet("hello", ["June", "July"], 10)

// Should be errors
greet()
greet("hello", "June")
greet(1, 2, 3, 4, 5, 6)

Custom runtime checking

Sometimes useful, frequently annoying.

function greet(greeting, months, age) {
  if (arguments.length !== 3)
    throw new Error('must be called with 3 arguments')
}

Custom runtime checking

Sometimes useful, frequently annoying.

function greet(greeting, months, age) {
  if (arguments.length !== 3)
    throw new Error('must be called with 3 arguments')
  if (typeof greeting !== 'string')
    throw new Error('greeting must be a string')
  if (!Array.isArray(months))
    throw new Error('months must be an array')
  if (typeof age !== 'number')
    throw new Error('age must be a number')
}

Custom runtime checking

React propTypes

Runtime type checking, but less annoying.

const MyThing = React.createClass({
  propTypes: {
    greeting: PropTypes.string,
    months: PropTypes.arrayOf(PropTypes.string),
    person: PropTypes.shape({
      name: PropTypes.string,
    })
  },
})

React propTypes

Static type checking

with flow!

flowtype.org

Static type checking

//                argument type  return type
function sayHello(name: string): string {
  return "Hello " + name
}






//

Static type checking

//                argument type  return type
function sayHello(name: string): string {
  return "Hello " + name
}
// you can annotate variables if you want
const age: number = 10
// but flow's clever enough to infer most things
const notherAge = 10
//    ^ flow knows that notherAge is a number

//

Static type checking

//                argument type  return type
function sayHello(name: string): string {
  return "Hello " + name
}
// you can annotate variables if you want
const age: number = 10
// but flow's clever enough to infer most things
const notherAge = 10
//    ^ flow knows that notherAge is a number
const greeting = sayHello("React")
//    ^ flow knows that greeting is a string!

Static type checking

// Look ma, no annotations!
function sayHello(name) {
  return "Hello " + name
}
// you can annotate variables if you want
const age: number = 10
// but flow's clever enough to infer most things
const notherAge = 10
//    ^ flow knows that notherAge is a number
const greeting = sayHello("React")
//    ^ flow knows that greeting is a string!

Static type checking

vs custom runtime checking

function greet(greeting, months, age) {
  if (arguments.length !== 3)
    throw new Error('must be called with 3 arguments')
  if (typeof greeting !== 'string')
    throw new Error('greeting must be a string')
  if (!Array.isArray(months))
    throw new Error('months must be an array')
  if (typeof age !== 'number')
    throw new Error('age must be a number')
}

function greet(greeting: string,
               months: Array<string>,
               age: number) {
}

Static type checking

vs React propTypes

class MyThing extends Component {
  static propTypes = {
    first: PropTypes.number,
    second: PropTypes.arrayOf(PropTypes.string),
    third: PropTypes.shape({
      name: PropTypes.string,
    })
  }
}

class Component extends MyThing {
  props: {
    first: number,
    second: Array<string>,
    third: {
      name: string,
    }
  }
}

Static type checking

Getting more type errors in JS

Reactions to Flow @ KA

• 😄 when adding flowtypes to code, it finds bugs!
• 😄 feel much safer making changes as a team
• 😄 code is self-documenting!
• 👎 editor integration is confusing
• 👎 new syntax + esnext can be overwhelming

Thinking with types

Thinking with types

• clever code
• implicit invariants
• implicit state machines
• write down data types first

Clever code

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

• Brian Kernighan

Clever code

clever

  props['on' + (fastClick ? 'MouseDown' : 'Click')] = myFn

unclever

  if (fastClick) {
    props.onMouseDown = myFn
  } else {
    props.onClick = myFn
  }

Clever code

messing w/ arguments

  function doAllTheThings(first, second, third) {
    if (third === undefined) {
      third = second
      first = {options: first}
    }
  }

"flag" arguments

  function doAllTheThings(dataIsBoolean, data) {
    if (dataIsBoolean) { // data is a boolean
    } else { // data is a string
    }
  }

If it's hard to type check, it's probably hard to understand

Implicit invariants

Implicit invariants

  state: {
    loading: boolean,
    error: ?string,
    data: ?SomeObject,
  }
  render() {
    if (this.state.loading) return ...
    if (this.state.error || !this.state.data) return ...
    return <button onClick={this.onClick}>
      Click me!
    </button>
  }

Implicit invariants

  state: { loading: boolean, error: ?string, data: ?SomeObject }
  onClick = () => {
    // Flow errors: "this.state.data might be null"
    alert(this.state.data.name)
  }
  render() {
    if (this.state.loading) return ...
    if (this.state.error || !this.state.data) return ...
    return <button onClick={this.onClick}>
      Click me!
    </button>
  }

Implicit invariants

  state: { loading: boolean, error: ?string, data: ?SomeObject }
  onClick = () => {
    if (!this.state.data)
      throw new Error('lol this will never happen')
    alert(this.state.data.name)
  }
  render() {
    if (this.state.loading) return ...
    if (this.state.error || !this.state.data) return ...
    return <button onClick={this.onClick}>
      Click me!
    </button>
  }

Implicit invariants

  render() {
    if (this.state.loading) return ...
    if (this.state.error || !this.state.data) return ...
    return <TheContents data={this.state.data} />
  }
}
class TheContents extends Component {
  props: {data: SomeObject}
  onClick = () => {
    alert(this.props.data.name) // props.data is never null!
  }
  render() {
    return <button onClick={this.onClick}>Click me!</button>
  }

Implicit state machines

Example: KA mobile app

Loading

Answering

Finished

The naive state representation

type State = {
  loading: boolean,
  problems: ?Array<Problem>,
  answers: ?Array<Answer>,
  currentProblem: number,
  pointsData: ?PointsData,
}

The naive state representation

// Loading problems
state = {
  loading: true,
  problems: null,
  answers: null,
  currentProblem: 0,
  pointsData: null,
}

// Answering
state = {
  loading: false,
  problems: [...some array],
  answers: [...some array],
  currentProblem: 3,
  pointsData: null,
}

// Finished
state = {
  loading: false,
  // not relevant anymore
  problems: [...some array],
  answers: [...some array],
  currentProblem: 0,
  pointsData: {some data},
}

The naive state representation

Allows illegal states

type State = {
  loading: boolean,
  problems: ?Array<Problem>,
  answers: ?Array<Answer>,
  currentProblem: number,
  pointsData: ?PointsData,
}

state = {
  loading: false,
  problems: [...some array],
  answers: null, // oops
  currentProblem: 0,
  pointsData: null,
}

Representing the state machine

Make illegal states invalid

// swift-land
enum State {
  case Loading
  case Answering(
    problems: Array<Problem>,
    answers: Array<Answer>,
    currentProblem: int
  )
  case Finished(PointsData)
}

Representing the state machine

Make illegal states invalid

// Flow-land, a "tagged union"
type State = {
  screen: 'loading',
} | {
  screen: 'answering',
  problems: Array<Problem>,
  answers: Array<Answer>,
  currentProblem: number,
} | {
  screen: 'finished',
  pointsData: PointsData
}

If you're making a ton of things optional, you're probably trying to represent a state machine poorly.

Write down data types first

Write down data types first

type Post = {
  title: string,
  createDate: Date,
  contents: string,
  authors: Array<{
    name: string,
    location: string,
    numberOfPosts: number,
  }>,
}

Thinking with types

• avoid clever code
• make invariants explicit
• make state machines explicit
• write down data types first

When 80% typed isn't enough

20% unsafe can very well mean 100% of users see bugs.

When 80% typed isn't enough

Library functions are "any" by default

// @flow

// If we don't have a type declaration set up for this
// external library, it gets treated as "any"
import _ from 'underscore'

const criticalFunction = (config: {name: string}): number => {
  return _.pick(config, 'name').naem // lol no errors
}

When 80% typed isn't enough

You'll use "any" to just get on with things

// TODO make a type for config
const criticalFunction = (config: any) => {
  // all bets are off for inference about config!
  // ...
}

Flow & TypeScript compromise soundness

What if you want more?

• Elm
• Reason/OCaml
• (lots of others too)

Elm

• 👍 solid documentation
• 👍 friendly error messages
• 👍 coherent tooling
• 🚫 very locked down JS interop
• 🚫 fairly young language / type system
• 🚫 I can't stand the syntax

Reason/OCaml

• 👍 very mature language
• 👍 awesome type system
• 👍 very pragmatic (mutability)
• 👍 excellent JS interop
• 👍 can also compile to native
• 🚫 horrid documentation
• 🚫 build tooling still settling

Comparison of the things

Flow or TypeScript?

Conclusion

• JavaScript doesn't give us enough type errors
• Static type checking can help!
• Working with types will help you think better
• You might want a 100% type system instead of 80%

FIN

jaredforsyth.com/type-systems-js-dev