-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathelm-flow-typescript.html
executable file
·1223 lines (1092 loc) · 48.6 KB
/
elm-flow-typescript.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Type Systems for JavaScript</title>
<meta name="apple-mobile-web-app-capable" content="yes"/>
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>
<meta name="viewport"
content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
<link rel="stylesheet" href="reveal.js/css/reveal.css">
<!--<link rel="stylesheet" href="reveal.js/css/theme/white.css" id="theme">-->
<!--<link rel="stylesheet" href="reveal.js/css/theme/black.css" id="theme">-->
<link rel="stylesheet" href="reveal.js/css/theme/night.css" id="theme">
<!--<link rel="stylesheet" href="reveal.js/css/theme/simple.css" id="theme">-->
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="reveal.js/lib/css/zenburn.css">
<style>
/*pre code {*/
/*display: block;*/
/*padding: 0.5em;*/
/*background: #FFFFFF !important;*/
/*color: #000000 !important;*/
/*}*/
.right-img {
margin-left: 10px !important;
float: right;
height: 500px;
}
.todo:before {
content: 'TODO: ';
}
.todo {
color: red !important;
}
code span.line-number {
color: lightcoral;
}
</style>
<!-- Printing and PDF exports -->
<script>
var link = document.createElement('link');
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match(/print-pdf/gi) ? 'reveal.js/css/print/pdf.css' : 'reveal.js/css/print/paper.css';
document.getElementsByTagName('head')[0].appendChild(link);
</script>
<!--[if lt IE 9]>
<script src="reveal.js/lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<!--Addtional Ideas-->
<!-- - Add D3 V4 TypeScript declarations as example for subsequent talks with emphasis on Java-->
<!-- - Uncle Bob thinks this is evil: http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html-->
<!-- - Maybe include as an additional idea when asking if you should use a type System in the version for JavaScript people-->
<!--Sources and additional ideas-->
<!-- - https://medium.com/@raxwunter/secret-flow-types-86b2ebb30951#.tkhjhdhf1-->
<!-- - Include more stuff from sources-->
<!-- - https://blogs.msdn.microsoft.com/typescript/2016/12/14/writing-dts-files-for-types/-->
<!-- - https://medium.com/@danvdk/a-typed-pluck-exploring-typescript-2-1s-mapped-types-c15f72bf4ca8#.yshmb6m67-->
<!-- - https://blogs.msdn.microsoft.com/premier_developer/2016/12/28/unit-testing-using-typescript-mocha-chai-sinon-and-karma/-->
<!-- - https://www.youtube.com/watch?v=IwVyroc__bM-->
<!--<section>-->
<!--<h3>Resources</h3>-->
<!--<ul>-->
<!--<li><a target="_blank"-->
<!--href="https://javascriptair.com/episodes/2016-08-31/">-->
<!--JavaScript Air | Typed JavaScript with TypeScript and
-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="http://blog.namangoel.com/flow-for-typescript-developers">-->
<!--Flow for TypeScript Developers-->
<!--</a>-->
<!--<li>Flow-->
<!--<ul>-->
<!--<li><a target="_blank"-->
<!--href="https://medium.com/@thejameskyle/flow-mapping-an-object-373d64c44592#.5fhfyngkf">-->
<!--Flow: Mapping an object-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://www.jetbrains.com/help/webstorm/2016.1/using-the-flow-type-checker.html">-->
<!--Flow in WebStorm-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://www.flowtype.org/blog/2016/08/01/Windows-Support.html">-->
<!--Official Windows binaries since August 2016-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://medium.com/@ikai/james-thanks-for-writing-this-795437144d08#.mbd4fyq3l">-->
<!--Medium uses Flow-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="http://www.robinwieruch.de/the-soundcloud-client-in-react-redux-flow/">-->
<!--Type Checking with Flow in React + Redux-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://github.com/flowtype/flow-typed">-->
<!--External Type Definitions-->
<!--</a>-->
<!--</ul>-->
<!--</li>-->
<!--<li>TypeScript-->
<!--<ul>-->
<!--<li><a target="_blank"-->
<!--href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript">-->
<!--What's new in TypeScript-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://github.com/Microsoft/TypeScript/wiki/Roadmap">-->
<!--Roadmap-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction">-->
<!--Anders Hejlsberg on Modern Compiler Construction-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-TypeScript-2">-->
<!--Anders Hejlsberg on TypeScript 2-->
<!--</a>-->
<!--<li><a target="_blank"-->
<!--href="https://vsavkin.com/functional-typescript-316f0e003dc6#.7pooz4sba">-->
<!--Functional TypeScript-->
<!--</a>-->
<!--</ul>-->
<!--</li>-->
<!--</ul>-->
<!--</section>-->
<section>
<h1>Type Systems for JavaScript</h1>
<h2><span class="elm">Elm, </span>Flow, and TypeScript</h2>
<p><small><a href="http://bit.ly/js-types">
http://bit.ly/js-types
</a></small></p>
<p>
<small><a href="http://zeigermann.eu">Oliver Zeigermann</a> / <a href="http://twitter.com/djcordhose">@DJCordhose</a>
</small>
</p>
<p><small><strong>If you are looking for the most recent and up-to-date version of my comparisons on Typed JavaScript you have just found it :)</strong></small></p>
</section>
<section>
<h2>Why using type systems?</h2>
<div class="fragment">
<h3>type systems make code easier to maintain</h3>
<p >type annotations / inferred types</p>
<ul >
<li>can make code more readable
<li>can make code easier to analyse
<li>can allow for reliable refactoring
<li>can allow for generally better IDE support
<li>can catch some (type related) errors early
</ul>
</div>
<p class="fragment"><a href="https://channel9.msdn.com/Events/Build/2016/B881" target="_blank">
Anders Hejlsberg@Build2016: <em>Big JavaScript codebases tend to become "read-only".</em>
</a></p>
</section>
<section>
<h3>weak to strong and dynamic to static</h3>
<div style="height: 580px">
<a href="https://twitter.com/DJCordhose/status/829242451294552066" target="_blank">
<img src="type-stragegies-twitter.png">
</a>
</div>
<p><small>
<a href="https://twitter.com/DJCordhose/status/829242451294552066" target="_blank">
https://twitter.com/DJCordhose/status/829242451294552066
</a>
</small></p>
</section>
<section>
<h2>http://stateofjs.com</h2>
<p>Recently published survey on the state of JavaScript</p>
</section>
<section>
<a href="http://stateofjs.com/2016/flavors/" target="_blank">
<img src="overview-percent.png" height="600px">
</a>
<p><small><a href="http://stateofjs.com/2016/flavors/" target="_blank">
http://stateofjs.com/2016/flavors/
</a></small></p>
</section>
<section>
<h2>TypeScript</h2>
<h3 class="fragment">ease of use and tool support over soundness</h3>
<ul class="fragment">
<li><a target="_blank" href="http://www.typescriptlang.org/">http://www.typescriptlang.org/</a>
<li>By Microsoft (Anders Hejlsberg)
<li>Based on ES6 (probably ES7/ES8)
<li>Adds optional type annotations, visibility, and decorators
<li>Compiler checks and removes annotations
<li>2.x with major changes released recently
<!--<li><a target="_blank" href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript">Latest 1.8 release adds more general sane checks</a>-->
<!--<li>External declarations can add type information to pure JavaScript-->
<!--<li>Extensive support in-->
<!--<a target="_blank" href="https://youtu.be/uceWBKISaF8">WebStorm</a> and Visual Studio Code-->
</ul>
</section>
<section>
<h2>Flow</h2>
<h3 class="fragment">soundness, no runtime exceptions as goal</h3>
<ul class="fragment">
<li><a target="_blank" href="http://flowtype.org/">http://flowtype.org/</a>
<li>By Facebook
<li><em>Flow is a static type checker, designed to quickly find errors in JavaScript applications</em>
<li>Not a compiler, but checker
<!--<li>Works without any type annotations-->
<!--<li>Very good at inferring types-->
<li>If present, type annotations can very easily be removed by babel for runtime
</ul>
</section>
<section class="elm">
<h2>Elm</h2>
<h3 class="fragment">simplicity, soundness, no runtime exceptions</h3>
<ul class="fragment">
<li><a target="_blank" href="http://elm-lang.org/">http://elm-lang.org/</a>
<li>Language of its own
<li>functional, not object-oriented
<li>no null, no mutation
<li>Geared torwards Web Appliations
<li>Compiler creates JavaScript
</ul>
</section>
<section>
<h2>Basics</h2>
</section>
<section>
<h3>TypeScript</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// variables can have type information
let foo: string;
foo = 'yo';
// Error: Type 'number' is not assignable to type 'string'.
foo = 10;
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// types can be inferred (return type)
function sayIt(what: string) {
return `Saying: ${what}`;
}
const said: string = sayIt(obj);
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
class Sayer {
what: string; // mandatory
constructor(what: string) {
this.what = what;
}
// return type if you want to
sayIt(): string {
return `Saying: ${this.what}`;
}
}
</code></pre>
</section>
<section>
<h3>Flow</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// variables can have type information
let foo: string;
foo = 'yo';
// Error: number: This type is incompatible with string
foo = 10;
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// types can be explicit (parameter) or inferred (return type)
function sayIt(what: string) {
return `Saying: ${what}`;
}
const said: string = sayIt(obj);
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
class Sayer {
what: string; // type also mandatory
constructor(what: string) {
this.what = what;
}
// return type if you want to
sayIt(): string {
return `Saying: ${this.what}`;
}
}
</code></pre>
</section>
<section>
<h2>Flow and TypeScript basics are pretty similar</h2>
<p>Those basic features help with documentation, refactoring, and IDE support</p>
</section>
<section class="elm">
<h3>Elm: a totally different story</h3>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
let
-- declaration using type
foo : String
foo = "yo"
-- Error: everthing is const, can not re-assign
foo = "yo yo"
foo2 : String
-- Error: `The definition of `obj2` does not match its type annotation.`
foo2 = 10
</code></pre>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
let
-- type annotations are optional, can be inferred
sayIt : String -> String
sayIt what =
"Saying: " ++ what
said : String
said = sayIt obj
</code></pre>
<p class="fragment">No classes and methods in elm</p>
</section>
<section>
<h2>Nullability</h2>
<p>One of my main sources of runtime exceptions when programming Java</p>
<p><small>Even after many years it is still surprising how many corner cases I miss in complex code</small></p>
</section>
<section class="flow">
<h3>Flow</h3>
<div class="fragment">
<p>what is the result here in pure JavaScript?</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
function foo(num) {
if (num > 10) {
return 'cool';
}
}
console.log(foo(9).toString());
</code></pre>
</div>
<pre class="fragment"><code class="javascript" contenteditable data-trim>
"Uncaught TypeError: Cannot read property 'toString' of undefined"
</code></pre>
<div class="fragment">
<p>What the flow checker thinks about this</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
// error: call of method `toString`.
// Method cannot be called on possibly null value
console.log(foo(9).toString());
</code></pre>
</div>
<div class="fragment">
<p>To fix this, we need to check the result</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
const fooed = foo(9);
if (fooed) {
fooed.toString();
}
</code></pre>
</div>
<p class="fragment">Types are non-nullable by default in flow</p>
</section>
<section class="typescript">
<h3>TypeScript</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// both TypeScript and flow allow
// to put the type annotation here instead of using inference
function foo(num: number) {
if (num > 10) {
return 'cool';
}
}
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// same as flow
const fooed: string|void = foo(9);
if (fooed) {
fooed.toString();
}
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// or tell the compiler we know better (in this case we actually do)
fooed!.toString();
</code></pre>
<div class="fragment">
<p>Only applies to TypeScript 2.x</p>
<p>Only works when <em>strictNullChecks</em> option is checked</p>
<p>All types nullable by default in TypeScript 1.x</p>
</div>
</section>
<section class="elm">
<h3>Elm</h3>
<p class="fragment">There neither is <code>null</code> nor <code>undefined</code> in elm</p>
<p class="fragment">Rather
<a target="_blank" href="https://guide.elm-lang.org/error_handling/maybe.html">Maybe</a> plus pattern matching</p>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
-- Maybe is predefined
-- http://package.elm-lang.org/packages/elm-lang/core/latest/Maybe
type Maybe a = Nothing | Just a
</code></pre>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
foo : Int -> Maybe String
foo num =
if num > 10 then
Just "cool"
else
Nothing
</code></pre>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
-- pattern matching (need to match all cases)
case (foo 11) of
Just message -> message
Nothing -> ""
</code></pre>
</section>
<section>
<h3>Generic Type information</h3>
<p class="fragment">Types can be parameterized by others</p>
<p class="fragment">Most common with collection types</p>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
let cats: Array<Cat> = []; // can only contain cats
let animals: Array<Animal> = []; // can only contain animals
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="3">
// nope, no cat
cats.push(10);
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="5">
// nope, no cat
cats.push(new Animal('Fido'));
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="7">
// cool, is a cat
cats.push(new Cat('Purry'));
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="9">
// cool, cat is a sub type of animal
animals.push(new Cat('Purry'));
</code></pre>
</section>
<section>
<h3>Up to this point this pretty much works in Flow and TypeScript the same way ...</h3>
</section>
<section>
<h3>... but wait</h3>
</section>
<section>
<h3>TypeScript</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
let cats: Array<Cat> = []; // can only contain cats
let animals: Array<Animal> = []; // can only contain animals
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="3">
// error TS2322: Type 'Animal[]' is not assignable to type 'Cat[]'.
// Type 'Animal' is not assignable to type 'Cat'.
// Property 'purrFactor' is missing in type 'Animal'.
cats = animals;
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="7">
// wow, works, but is no longer safe
animals = cats;
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="9">
// because those are now all cool
animals.push(new Dog('Brutus'));
animals.push(new Animal('Twinky'));
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="12">
// ouch:
cats.forEach(cat => console.log(`Cat: ${cat.name}`));
// Cat: Purry
// Cat: Brutus
// Cat: Twinky
</code></pre>
<p class="fragment">TypeScript allows for birds and dogs to be cats here :)</p>
</section>
<section>
<h3>Flow</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
let cats: Array<Cat> = []; // can only contain cats
let animals: Array<Animal> = []; // can only contain animals
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="3">
// ERROR
// property `purrFactor` of Cat. Property not found in Animal
cats = animals;
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="6">
// same ERROR
animals = cats;
</code></pre>
<p class="fragment">Flow does not have have this caveat</p>
</section>
<section>
<h2>The flipside</h2>
<p>This code is safe (as we access cats in a readonly fashion)</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
function logAnimals(animals: Array<Animal>) {
animals.forEach(animal => console.log(`Animal: ${animal.name}`));
}
logAnimals(cats);
</code></pre>
<ul class="fragment">
<li>This works in TypeScript (and it should)</li>
<li>however, potentially not safe, there is nothing to keep us from writing to cats</li>
<li>Flow does not allow this, even though it is safe</li>
</ul>
<div class="fragment">
<p>much despised Java generics excel here as they can actually make that code safe (another difference:
<a target="_blank" href="https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Comparing_declaration-site_and_use-site_annotations">
Use-site variance
</a>)
</p>
<pre><code class="java line-numbers" contenteditable data-trim>
// Java
void logAnimals(List<? extends Animal> animals) {
animals.forEach(animal -> System.out.println("Animal: " + animal.name));
// illegal:
animals.add(new Animal("Twinky"));
}
</code></pre>
</div>
</section>
<section>
<h3>Some Type Inference Magic</h3>
<p>Consider</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
class Dog { woof() { } }
const animals = [];
animals.push(new Dog());
</code></pre>
<div class="fragment">
<p>both TypeScript and Flow know this is safe, as we have only added Dogs so far</p>
<pre><code class="typescript line-numbers" contenteditable data-trim data-num-start="5">
animals.forEach((animal: Dog) => animal.woof());
</code></pre>
</div>
<div class="fragment">
<p>Adding Cats <em>later</em> and thus changing array type later</p>
<pre><code class="typescript line-numbers" contenteditable data-trim>
class Cat { meow() { } }
animals.push(new Cat());
</code></pre>
<p>does not affect TypeScript (correct), but makes Flow fail</p>
</div>
</section>
<section class="elm">
<h3>Elm</h3>
<p class="fragment">does not have classes or subtypes</p>
<p class="fragment">has Records (like JavaScript Objects) and generic data structures (e.g. List)</p>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim data-leftpad>
type alias Animal = { name : String }
someAnimal1 = { name = "Patrick"}
animals : List Animal -- generic data structure
animals = [ someAnimal1, someAnimal2, ... ]
</code></pre>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim data-leftpad data-num-start="4">
type alias Cat = { name : String, coatColor : String }
cats : List Cat
cats = [ someCat1, someCat2, ... ]
</code></pre>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim>
-- sure
moreAnimals : List Animal
moreAnimals = animals
-- Error: Looks like a record is missing the `coatColor` field.
evenMoreAnimals : List Animal
evenMoreAnimals = cats
-- nope, same problem
moreCats : List Cat
moreCats = animals
</code></pre>
</section>
<section>
<h3>Differences in Generic Types</h3>
<ul>
<li class="fragment">TypeScript
<ul>
<li><a target="_blank" href="https://twitter.com/ahejlsberg/status/822882400724131841?s=03">always covariant</a> (more special):<br>
parametric types are compatible if the type to assign from has a more special type parameter</li>
<li>seems most intuitive, allows for obviously wrong code, though
</ul>
</li>
<li class="fragment">Flow
<ul>
<li>
<a href="https://flowtype.org/docs/classes.html#polymorphism-and-type-parameter-variance"
target="_blank">
using generic types you can choose from invariant (exact match), covariant <em>+</em> (more special), and contravariant <em>-</em> (more common)</a></li>
<li>Array in Flow has an invariant parametric type
<li>more expressive, harder to master, disallows some correct code
</ul>
</li>
<li class="fragment elm">Elm
<ul>
<li>Generic data structures using type variables
<li>all types have to match exactly
</ul>
</ul>
<!--<p class="fragment">Both Flow and TypeScript support upper, but not lower bounds</p>-->
</section>
<section>
<h3>Bounds in Generics</h3>
<p>Both Flow and TypeScript support upper, not lower bounds</p>
<p>Both Flow and TypeScript support
<a target="_blank" href="https://en.wikipedia.org/wiki/Bounded_quantification#F-bounded_quantification">
F-Bounded Polymorphism
</a>
</p>
<p><a target="_blank" href="https://flowtype.org/blog/2015/03/12/Bounded-Polymorphism.html">https://flowtype.org/blog/2015/03/12/Bounded-Polymorphism.html</a></p>
<p><a target="_blank" href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#type-parameters-as-constraints">https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#type-parameters-as-constraints</a></p>
</section>
<section class="elm">
<h3>Mutation, const</h3>
<p class="fragment"><strong>TypeScript and flow</strong>: same as JavaScript (const optional, immutable via lib)</p>
<p class="fragment"><strong>TypeScript</strong>: readonly for properties</p>
<p class="fragment"><strong>Elm</strong>: everything always immutable and const</p>
</section>
<section class="elm">
<h3>`Changing` records in Elm</h3>
<p class="fragment">Central Question: If everything always immutable and const, how do you make modifications?</p>
<p class="fragment">Answer:</p>
<ul class="fragment">
<li>you do not really make mutations
<li>instead create a new record
<li>taking over some of the properties of the old record and
<li>setting some new properties
</ul>
<div>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
type alias Cat = { name : String, coatColor : String, age: Int}
someCat = { name = "Purry", age = 2, coatColor = "gray"}
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="3">
haveBirthday : Cat -> Cat
haveBirthday cat =
-- make a copy, but with changed age
{ cat | age = cat.age + 1 }
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim data-num-start="6">
agedCat : Cat
agedCat = haveBirthday someCat
</code></pre>
</div>
</section>
<section>
<h3>`any` type</h3>
<p class="fragment">can be anything, not specified</p>
<p class="fragment">can selectively disable type checking</p>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
function func(a: any) {
return a + 5;
}
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// cool
let r1: string = func(10);
// cool
let r2: boolean = func('wat');
</code></pre>
<ul>
<li class="fragment"><em>flow / TypeScript 2</em>: explicit any supported, but any never inferred
<li class="fragment elm"><em>Elm</em>: does not exist, everything has exact type
</ul>
</section>
<section>
<h2>Union Types</h2>
<p class="fragment">aka Disjoint Unions aka Tagged Unions aka Algebraic data types</p>
<p class="fragment">to describe data with weird shapes</p>
<p class="fragment">depending on some data other data might apply or not</p>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
// a disjoint union type with two cases
type Response = Result | Failure;
type Result = { status: 'done', payload: Object }; // all good, we have the data
type Failure = { status: 'error', code: number}; // error, we get the error code
</code></pre>
</section>
<section>
<h3>Implementation both in Flow and TypeScript</h3>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-trim>
function callback(response: Response) {
// works, as this is present in both
console.log(response.status);
// does not work,
// as we do not know if it exists, just yet
console.log(response.payload); // ERROR
console.log(response.code); // ERROR
</code></pre>
<pre class="fragment"><code class="typescript line-numbers" contenteditable data-num-start="7"> switch (response.status) {
case 'done':
// this is the special thing:
// type system now knows, this is a Result
console.log(response.payload);
break;
case 'error':
// and this is a Failure
console.log(response.code);
break;
}
} </code></pre>
</section>
<section class="elm">
<h3>Elm</h3>
<p class="fragment">simple and concise union types</p>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim data-leftpad>
type Response = Result String | Failure Int
</code></pre>
<p class="fragment">switching over union type alternatives using pattern matching</p>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim data-num-start="3" data-leftpad>
callback : Response -> String
callback response =
-- pattern matching
case response of
Result payload -> payload
Failure code ->
if code >= 400 && code < 500 then "you messed up"
else "we messed up"
</code></pre>
<p class="fragment">usage</p>
<pre class="fragment"><code class="elm line-numbers" contenteditable data-trim data-num-start="10" >
callback (Result "response")
-- response
callback (Failure 404)
-- you messed up
</code></pre>
</section>
<section>
<h1>Are Flow and TypeScript like Java/C++/C#?</h1>
</section>
<section>
<h2>Not really</h2>
<ul>
<li class="fragment">Both
<ul>
<li>optionally typed / any
<li>built to match common JavaScript programming patterns
<li>type systems more expressive
<li>type inference
<li>control flow based type analysis
</ul>
</li>
<li class="fragment">TypeScript
<ul>
<li>semantically compatible with JavaScript
</ul>
</li>
<li class="fragment">Flow
<ul>
<li>just a checker
<li>not even a language of its own
<li>non-nullability as default
</ul>
</li>
</ul>
</section>
<section>
<h3>Nominal Typing for Flow classes</h3>
<pre><code class="typescript line-numbers" contenteditable data-trim>
class Person {
name: string;
}
class Dog {
name: string;
}
let dog: Dog = new Dog();
// nope, nominal type compatibility violated
let person: Person = dog; // ERROR: Dog: This type is incompatible with Person
// same problem
let person: Person = { // ERROR: object literal: This type is incompatible with Person
name: "Olli"
};
</code></pre>
</section>
<section>
<h3>Structural Typing for TypeScript classes</h3>
<pre><code class="typescript line-numbers" contenteditable data-trim>
class Person {
name: string;
}
class Dog {
name: string;
}
let dog: Dog = new Dog();
// yes, correct, as structurally compatible
let person: Person = dog;
// same thing, also correct
let person: Person = {
name: "Olli"
};
</code></pre>
</section>
<section>
<h2>Structural vs Nominal Typing</h2>
<ul>
<li class="fragment">Nominal Typing: types are compatible when their declared types match
<li class="fragment">Structural Typing: types are compatible when their structures match
<li class="fragment">Java, C#, C++, C all use nominal typing exclusively
<li class="fragment">Flow classes are also treated as nominal types
<li class="fragment">TypeScript classes are treated as structural types
<li class="fragment">Everything else in both Flow and TypeScript uses structural typing
<li class="fragment elm">Elm always uses structural typing with exact matches on Records
</ul>
</section>
<section>
<h3>Structural Typing for both TypeScript and Flow</h3>
<pre><code class="typescript line-numbers" contenteditable data-trim>
interface NamedObject {
name: string;
}
// this is fine as nominal typing only applies to Flow classes
let namedObject: NamedObject = dog;
// same thing, also fine
let namedObject: NamedObject = {
name: "Olli"
};
// not fine in either, missing name
let namedObject: NamedObject = {
firstName: "Olli"
};
</code></pre>
</section>
<section>
<h2>Classes in TypeScript</h2>
<p class="fragment">TypeScript has special support for classes</p>
<p class="fragment">Similar features can be found in Java/C++/C#</p>
<ul class="fragment">
<li><em>abstract</em> classes and methods
<li>special shortcut constructors (combined definition of fields and initialization)
<li>public, private, protected
<li>decorators (aka <a target="_blank" href="https://msdn.microsoft.com/en-us/library/z0w1kczw(v=vs.80).aspx">
Attributes in C#
</a> and <a target="_blank" href="https://docs.oracle.com/javase/tutorial/java/annotations/">
Annotations in Java</a>)
<li>
<a target="_blank"
href="https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/">
readonly properties
</a>
(TypeScript 2)
<a target="_blank" href="https://msdn.microsoft.com/en-us/library/acdd6hb7.aspx">
like in C#
</a>
</ul>
<p class="fragment">Flow does not feature those or any other syntactic sugar, as it is a checker only</p>
</section>
<section>
<h2>Integration with raw JavaScript</h2>
</section>
<section>
<h3>3rd Party Libraries in Flow</h3>
<ul>
<li>Core Declarations come with Flow Checker, includes React
<li>Other external declarations are optional
<li><a target="_blank"
href="https://github.com/flowtype/flow-typed">
External Flow Type Definitions
</a>
<li>some libraries even come with added flow type declarations (e.g. immutable.js)
<li><a target="_blank"
href="https://flowtype.org/docs/third-party.html">
Declarations can be added to flow config files
</a>
<li>If there are no existing declaration files: still works, but less powerful
</ul>
</section>
<section>
<h3>TypeScript Declaration files</h3>
<ul>
<li>Much larger base for external declarations <a href="https://github.com/DefinitelyTyped/DefinitelyTyped" target="_blank">DefinitelyTyped</a>
<li>TypeScript 1.x
<ul>
<li>needed External Type Declarations for 3rd party libraries</li>
<li>turned out to be a major PITA</li>
</ul>
</li>
<li>TypeScript 2.x
<ul>
<li>like Flow</li>
<li>install external type declarations transparently <a href="https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/" target="_blank">using npm</a>
(e.g.<em>npm install @types/react --save</em>)
</ul>
</li>
</ul>
</section>
<section class="elm">
<h3>Using JavaScript Code in Elm</h3>
<ul>
<li>in practice, most production Elm projects end up wanting to access the JS ecosystem
<li>integration works via messages through ports (<a target="_blank"
href="https://guide.elm-lang.org/interop/javascript.html">
https://guide.elm-lang.org/interop/javascript.html
</a>)
<li>Only part of the app where there can still be runtime exceptions
<li>data from JavaScript sent like JSON
<li>needs to be converted and typed in Elm
</ul>
</section>
<section>
<h2>IDE Support</h2>