Typescript 2.4

[spacejack]

@isiahmeadows, @andraaspar I've added the branch ts2.4 to experiment with solutions. Running npm i will install TS2.4.

I've added @andraaspar's most recent updates currently in PR at DT. (Failing tests commented out because I haven't setup DT's linting system for this repo.)

This branch also contains default generic parameters that I'd like to submit in a followup PR. (See here for example.)

Currently the Lifecycle type has an additional member to get around the new "weak types" checking feature in TS2.4. This leaves us with slightly weaker component types. Using a numeric key improves the situation but it's not quite perfect. (You could write component[0].)

There is also this outstanding problem with ClassComponent: #21

[dead-claudia]

@spacejack Would it be better if we just unified component instances like below and then just inlined Lifecycle's members into the component and attrs types? It'd also fix #21 by side effect.

• Object components: interface Component<Attrs, State extends Component<Attrs, State>> { ... }
• Class components: new <S extends Component<Attrs, S>>(vnode: Vnode<Attrs, S>) => S
• Closure components: <S extends Component<Attrs, S>>(vnode: Vnode<Attrs, never>) => S

(Note that I preserve the State extends Component invariant for objects, even though core doesn't require it.)

[spacejack]

@isiahmeadows I'm a bit stumped on this one, it seems to lead down a rabbit-hole of inlining (there are also Vnode types to consider.)

I looked at moving view into Lifecycle, but then State doesn't satisfy the constraints.

[dead-claudia]

What other nodes implicitly implement Lifecycle?