Seeking System Zen with Universal TypeScript

Transcript

1. SEEKING SYSTEM ZEN WITH UNIVERSAL TYPESCRIPT
2. THE LIFE OF A FULL STACK DEV What kinds of problems do we have? ▸ Getting FE and BE to communicate ▸ Many external systems ▸ Keeping a big, polyglot stack running reliably
3. BUT WHAT KINDS OF PROBLEMS WOULD WE LIKE TO HAVE? ▸ Domain problems ▸ UX problems ▸ hard problems.
4. UNFORTUNATELY, OUR ENERGY GETS WASTED ON THE Boring Stuff INSTEAD OF THE Good Stuff.
5. HOW DO WE PROTECT OURSELVES FROM Boring Problems?
6. WE WRITE TESTS. LOTS OF THEM.
7. THE TROUBLE IS, WE'RE human. We are super terrible at enumerating all conditions. Consider: ▸ Edge cases ▸ Error states ▸ Future refactoring
8. GUESS WHO IS REALLY GOOD AT IT, THOUGH?
9. COMPUTERS!
10. SO, WE'VE GOT A COMMUNICATION GAP HERE Computers are good at... ▸ Fast calculations ▸ Big datasets Humans are good at... ▸ Pattern recognition
11. WE CAN AGREE ON CONSTRAINTS That's why we use math to communicate with computers.
12. SO WHEN ARE WE GONNA GET TO THE TYPESCRIPT? Right now! Let's talk about what TS is.
13. TYPESCRIPT IS... A statically-, structurally- typed superset of JavaScript that compiles to plain JavaScript.
14. THE TYPE SYSTEM IS STRICTLY A tool FOR YOU, THE DEVELOPER.
15. CHEAP, INSTANT TESTS
16. WHAT CAN'T WE TEST?
17. LEVERAGING THE TYPE SYSTEM
18. FUNCTIONAL PROGRAMMING A CRASH COURSE
19. The core of FP is: TREATING COMPUTATION AS THE EVALUATION OF MATHEMATICAL FUNCTIONS.
20. Instead of: ▸ first do A to x ▸ then do B to x ▸ evaluate x We say: ▸ y = f(g(x))
21. if... ▸ g(x) maps from verbalOrders to drinks, ▸ f(x) maps from drinks to baristaInstructions then... We can safely compose f(g(x)) & statically prove that our OrderTaker works.
22. SO WHAT DOES VALID MEAN, ANYWAY?
23. DOMAIN TYPES!
24. SO WHAT? Let's take a look at the frontend.
25. BUILDING A FRONTEND WITH TYPESCRIPT Our principles: ▸ Functional style ▸ Tightly constrained inputs and outputs
26. PICKING A FRAMEWORK The ideal framework for a type-first UI would: ▸ Declaratively generate UI ▸ Describe visual components as pure functions of inputs
27. A TOUR
30. So, we have UI that takes tightly scoped types as inputs. What if we used our domain types as inputs to that UI?
31. BOOM. MATHEMATICALLY VALIDATED REPRESENTATION OF THE DOMAIN.
32. Design! IN YOUR SOURCE CODE!
33. AN ASIDE, ON FLEXIBLE COMPONENTS
34. COOL. SO, WHAT ABOUT THE BACKEND?
35. A backend's job is to gather and manipulate data.
36. LET'S CHECK IT OUT.
38. INSTANT. COMPILE-TIME. SYSTEM TEST.
39. YOUR TYPES ARE YOUR bones.
40. OKAY, SO. THIS DOESN'T MEAN THERE'S NO WORK INVOLVED.
41. WE'RE JUST SAVING OUR ENERGY FOR THE hard problems.
42. Thanks to: ▸ Drew Colthorp for sharing the tech stack & all the TS knowledge ▸ Atomic Object for being an awesome place full of awesome FP nerds ▸ The TypeScript Team for building a rad-as-heck language Rachael McQuater rachael.mcquater@atomicobject.com See also: https://github.com/atomicobject/ts-react-graphql-starter-kit https://github.com/atomicobject/ts-workshop