Presentation for React Zagreb meetup on 22nd of February 2018. Covers an intro level of Flow and TypeScript and why you would use them.

1. Flow or Type - how
to React to that?
Domagoj Cerjan
Kresimir Antolic

2. WHAT TO EXPECT?

3. Nothing revolutionary.
Hints and cases where *THIS* can help you!
Enough for you to start believing in the TYPE.

4. THE PROBLEM

5. ● Familiar with these?
● What is the second argument of that function?
● I removed a function from a module, what code used it and where will it break?

6. OUR LORD AND SAVIOUR…*
* Not really but it helps A LOT.

7. ● A safeguard preventing us from assigning apples to oranges
● A tool which helps to avoid ‘undefined is not a function’ or ‘cannot read property x of
undefined’ errors
● Gives a sense of hope and security in huge codebases
● Makes refactoring a little less heart attack prone
● Makes code more clear and explicit
A Type System!

8. IN REACT?!

9. … Not exactly.
● Around the React ecosystem… Yeah
● Not tied directly but it makes our life easier
● Defining input for your components and describing your data

10. API DATA
TRANSFORM
DATA
API DATA
TRANSFORM
DATA
COMBiNE
TRANSFORM
UI
REACT
COMPONENT
LOCAL
DATA
INTERACTION!
MODIFY
FUNCTION
CALL
DATA

11. OK.. WHAT THEN?

12. Flow
● Type-checking preprocessor bolted
onto JS
● More oriented towards FP
● Requires a type annotation removal
step before JS code can be consumed
(usually via @babel/preset-flow)
Typescript
● Actual language with its own
compiler
● More oriented towards OOP
● Has enums (it is a different
language)
● Requires a compilation step to
produce runnable JS code (via tsc)
Type System{s}?

13. Flow
● Prioritizes soundness - it rejects all
invalid code and some valid
● Type-related bugs do not slip through
● Objects, Interfaces and Functions are
structurally typed
● Classes are nominally typed (ie two
differently named classes having exact
same shape are different)
Typescript
● Prioritizes completeness - accepts
all valid code and some invalid
● Type-related bugs might slip
through
● Objects and Interfaces are
structurally typed
● Classes, Functions and somewhat
Enums are nominally typed
Type System{s}? - Continued

14. OK OK...
WHAT TO EXPECT?

15. Making sure an apple is an apple
Types

16. let call: number = 'maybe';
// Type '"maybe"' is not assignable to type 'number'
call = 2;
class Apple { private name: string; }
class Orange { private name: string; }
let thing: Apple;
thing = new Apple();
thing = new Orange();
// Type 'Orange' is not assignable to type 'Apple'.
// Types have separate declarations of a private property 'name'.
Typescript

17. let call: number = 'maybe';
// Cannot assign 'maybe' to call because string [1] is incompatible with number [2].
call = 2;
class Apple { _name: string; }
class Orange { _name: string; }
let thing: Apple;
thing = new Apple();
thing = new Orange();
// Cannot assign new Orange() to thing because Orange [1] is incompatible with Apple [2].
Flow

18. Describing contents in the box
Interfaces/Types

19. type PokemonType = 'water' | 'fire' | 'electric';
interface IPokemon {
name: string;
type: PokemonType[];
}
interface IProps {
list: IPokemon[];
}
interface IState {
isExpanded: boolean;
}
export class PokemonList extends React.PureComponent<IProps, IState> {
state = { isExpanded: false };
render() {
const { list } = this.props;
return list ? (<div>{list.map((p) => <div>{p.name}</div>)}</div>) : null;
}
}
Typescript

20. type PokemonType = 'water' | 'fire' | 'electric';
interface IPokemon {
name: string;
type: PokemonType[];
}
interface IProps {
list: IPokemon[];
}
interface IState {
isExpanded: boolean;
}
export class PokemonList extends PureComponent<IProps, IState> {
state = { isExpanded: false };
render() {
const { list } = this.props;
return list ? (<div>{list.map((p) => <div>{p.name}</div>)}</div>) : null;
}
}
Flow

21. Where type systems shine
Inference

22. class Apple { private name: string; }
class Orange { private name: string; }
const fruitBox = [new Orange(), new Orange(), new Apple()]
const makeOrangeJuice = (oranges: Orange[]): string =>
`Orange juice (${oranges.length})dl`;
makeOrangeJuice(fruitBox);
// Type 'Apple' is not assignable to type 'Orange'.
// Types have separate declarations of a private property 'name'.
Typescript

23. class Apple { _name: string; }
class Orange { _name: string; }
const fruitBox = [new Orange(), new Orange(), new Apple()]
const makeOrangeJuice = (oranges: Orange[]): string =>
`Orange juice (${oranges.length})dl`;
makeOrangeJuice(fruitBox);
// Cannot call makeOrangeJuice with fruitBox bound to oranges because Apple [1] is incompatible with Orange [2] in
array element.
Flow

24. :any is the enemy, believe in type inference
● Using :any type turns type inference off, any is bad, don’t be like any
● We don’t want to type types manually everywhere
● Humans make mistakes often, some developers do also
● Type inference systems usually don’t, but when they do, they do it consistently
● Do not assume types, let type inference do that for you!
● Relying on type inference mechanisms allows us to think less and code more

25. Organizing your boxes
Structuring your app

26. export class Pokemon {
static readonly type: string = 'electric';
public height: number = 0.5;
protected pokemonIdx: number = 0;
private name: string = 'pikachu';
constructor() {
console.log(this.name);
}
}
Typescript

27. export class Pokemon {
static +type: string = 'electric';
height: number = 0.5;
pokemonIdx: number = 0;
_name: string = 'pikachu';
constructor() {
console.log(this._name);
}
}
Flow

28. Working with the codebase
Stick, stones, wood, lava..

29. Flow
● IDE integration is lacking
compared to Typescript
● Slow, though improving a lot with
every new release
● Outstanding command line tools
● ESLint with flow-type plugin
Typescript
● Great IDE integration (Idea, VSCode...)
● Fast
● Excellent code-completion facilities
● Ok-ish command line tools
● Parallelised type checking
● TSLint (though lacking in comparison
with ESLint)
Working with the codebase

30. Working well with others?
● Both flow and typescript offer facilities to define library typings
○ Flow via *.flow.js files
○ Typescript via *.d.ts files
● Most commonly used libraries (lodash, react, redux…) have well-tested
and defined typings which provide both code completions and type-safety
● You can always extend, override or write yours

31. It's leviosa not leviosa
Advanced usages

32. Advanced usages
● Code generation!
○ Gives type safety on multiple levels
● Generic types
● Nominal vs Structural typing
● Type unions and intersections

33. GREAT - LET’S MOVE TO TYPES!

34. When to migrate?
When to migrate to either Typescript or Flow
● Big crucial project
● High people turnover rate
● Aiming to increase robustness of the project codebase
● OOP oriented - Typescript
● FP oriented - Flow
When not to think about it
● Small and simple project

35. Issues?
● Flow - opt in , TS - have to write everything..
● 3rd party typings - But sometimes… those typings leave a lot to be desired
● TS - if things are not easily typed.. Maybe you didn’t structure your code well

36. NO MORE ERRORS, NEVER?

37. Bad things...
● Type systems do not solve all of your mistakes, they only prevent some from happening
● They introduce complexity
● More programming knowledge is needed (Types? What are those?)
● You still need to know JS
● They don't make JS more performant
● Can lead to over-engineering
● Illusion of security (mistyped libraries, abusing any type)

38. OTHER SOLUTIONS?

39. ● Elm - a Haskell inspired purely functional typed language that compiles down to JS
● Purescript - a Haskell inspired purely functional statically typed language that compiles down to JS
● Livescript - a Haskell, F# and clojure inspired functional statically typed language that also compiles
down to JS
● Dart - Google’s attempt at replacing JS - a more classical optionally-typed language that, you
guessed it, compiles down to JS
● Haxe - a strictly typed general purpose multi-paradigm language that also happens to also target JS
● All of that is great but it introduces new concepts, a new language and a new set of problems which
could be problematic for onboarding new people not familiar to them
Other typed solutions

40. REMIND ME AGAIN WHY
SHOULD I DO THIS?

41. Why?
● Refactoring
● Codebase robustness
● Helps with high people turnover rate
● Ease of development (code completion)
● Auto documentation - “what type is that second argument of a function from
over there?!?”
● Readability, static code analysis - catch errors early!

42. JUST TYPE IT.

43. THANKS!
@kantolic
@dcerjan