Seeking System Zen with Universal TypeScript

Seeking System Zen with Universal TypeScript

F147ad44f6ea0bb0c0b7ad1133aae0ca?s=128

Rachael McQuater

November 30, 2018
Tweet

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

  28. None
  29. None
  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.

  37. None
  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