Flow or Type - how to React to that?
1 like137 views
The document discusses type systems in JavaScript, specifically Flow and TypeScript, comparing their features and usage. It highlights how these systems enhance code clarity, avoid common errors, and aid in refactoring while also outlining when to migrate to them. Challenges and misconceptions related to type systems are also addressed, emphasizing their role in improving code robustness despite introducing additional complexity.
![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](https://image.slidesharecdn.com/flowortype-howtoreacttothat-180222212401/85/Flow-or-Type-how-to-React-to-that-17-320.jpg)
![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](https://image.slidesharecdn.com/flowortype-howtoreacttothat-180222212401/85/Flow-or-Type-how-to-React-to-that-19-320.jpg)
![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](https://image.slidesharecdn.com/flowortype-howtoreacttothat-180222212401/85/Flow-or-Type-how-to-React-to-that-20-320.jpg)
![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](https://image.slidesharecdn.com/flowortype-howtoreacttothat-180222212401/85/Flow-or-Type-how-to-React-to-that-22-320.jpg)
![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](https://image.slidesharecdn.com/flowortype-howtoreacttothat-180222212401/85/Flow-or-Type-how-to-React-to-that-23-320.jpg)
Flow or Type - how to React to that?
- 1. Flow or Type - how to React to that? Domagoj Cerjan Kresimir Antolic
- 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
- 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.