I should add the remaining reducers

oops

I should make sure this is imported

adding babylon types

adding pref types is really helpful

contravariance?

yeah - i think that's right :)

@thejameskyle did i get it right?

Class methods are covariant in Flow by default, which in effect means they are "read-only" and cannot be assigned to.

class Error extends React.Component {
  constructor(props) {
    super(props);
    this.onClick = this.onClick.bind(this); // Error
    //   ^ property `onClick`. Covariant property `onClick` incompatible with contravariant use in
    //     assignment of property `onClick`
  }
  
  onClick(event: ButtonClickEvent) {
    // ...
  }
  
  render() {
    return <button onClick={this.onClick}>Click Me</button>;
  }
}

In order to make this work, you need to use an additional class field, which are invariant (read & write) by default, like this:

class WorksWithClassPropertyType extends React.Component {
  constructor(props) {
    super(props);
    this.onClick = this.onClick.bind(this); // Works!
  }
  
  onClick: (ButtonClickEvent) => void;
  onClick(event) {
    // ...
  }
}

Alternatively you can use the class properties proposal to get around all of this:

class WorksWithClassPropertyArrowFunction extends React.Component {
  onClick = (event: ButtonClickEvent) => {
    // ...
  };
}

[See in Try Flow]

@thejameskyle Great explanation, was wondering about why this happens myself too.

Is it the same case when I try to set custom toString() on some function?

const createActionCreator = (type, actionCreator) = {
  actionCreator.toString = () => type // error!
  return actionCreator
}

is there any workaround for this?

What was the difficulty with defaultProps?

adding static props in the class definition. I'll add that

I would also like to know what was difficult

The only caveat here is that it's sometimes useful to be able to "cheat" in tests, like pass in a mock object that doesn't match the full type but does just what this particular unit test needs.

true, I'm finding that now...

Generally type systems eliminate the need to do things like that. But you can do one of two things in that scenario:

1. Use Flow's suppress_comment option
2. Pass the value through any to stop type checking – I'd recommend doing this along with a comment explaining why it any is needed. Using any means you're less tied to configuration

function method(value: string) {
  if (typeof value === 'number') throw new TypeError('Support for numbers has been removed');
  return value;
}

test('throws deprecation error', () => {
  expect(() => {
    // Passing through `any` because we want to make sure we're throwing an error.
    method((42: any));
  }).toThrow(TypeError);
});

There are still a lot of anys, especially for callback functions and items stored in Immutable structures. Might be good to either review if they are trivially removable or, if there are real impediments, make a list of what they are.

Yes - there are. We should file bugs based on some of these next steps

React components?

racey?

I think this means that some related data can be set in a non-deterministic order based on how async actions happen to fire. (Especially true for things like parsing that happen in a separate web worker thread.) Flow makes us declare which things have to be present together and prove that all possible state transitions meet those rules.

Might want to explain it a bit more