Tweet
Tweet

Slide 1

Slide 1 text

SEEKING SYSTEM ZEN WITH UNIVERSAL TYPESCRIPT

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

BUT WHAT KINDS OF PROBLEMS WOULD WE LIKE TO HAVE? ▸ Domain problems ▸ UX problems ▸ hard problems.

Slide 4

Slide 4 text

UNFORTUNATELY, OUR ENERGY GETS WASTED ON THE Boring Stuff INSTEAD OF THE Good Stuff.

Slide 5

Slide 5 text

HOW DO WE PROTECT OURSELVES FROM Boring Problems?

Slide 6

Slide 6 text

WE WRITE TESTS. LOTS OF THEM.

Slide 7

Slide 7 text

THE TROUBLE IS, WE'RE human. We are super terrible at enumerating all conditions. Consider: ▸ Edge cases ▸ Error states ▸ Future refactoring

Slide 8

Slide 8 text

GUESS WHO IS REALLY GOOD AT IT, THOUGH?

Slide 9

Slide 9 text

COMPUTERS!

Slide 10

Slide 10 text

SO, WE'VE GOT A COMMUNICATION GAP HERE Computers are good at... ▸ Fast calculations ▸ Big datasets Humans are good at... ▸ Pattern recognition

Slide 11

Slide 11 text

WE CAN AGREE ON CONSTRAINTS That's why we use math to communicate with computers.

Slide 12

Slide 12 text

SO WHEN ARE WE GONNA GET TO THE TYPESCRIPT? Right now! Let's talk about what TS is.

Slide 13

Slide 13 text

TYPESCRIPT IS... A statically-, structurally- typed superset of JavaScript that compiles to plain JavaScript.

Slide 14

Slide 14 text

THE TYPE SYSTEM IS STRICTLY A tool FOR YOU, THE DEVELOPER.

Slide 15

Slide 15 text

CHEAP, INSTANT TESTS

Slide 16

Slide 16 text

WHAT CAN'T WE TEST?

Slide 17

Slide 17 text

LEVERAGING THE TYPE SYSTEM

Slide 18

Slide 18 text

FUNCTIONAL PROGRAMMING A CRASH COURSE

Slide 19

Slide 19 text

The core of FP is: TREATING COMPUTATION AS THE EVALUATION OF MATHEMATICAL FUNCTIONS.

Slide 20

Slide 20 text

Instead of: ▸ first do A to x ▸ then do B to x ▸ evaluate x We say: ▸ y = f(g(x))

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

SO WHAT DOES VALID MEAN, ANYWAY?

Slide 23

Slide 23 text

DOMAIN TYPES!

Slide 24

Slide 24 text

SO WHAT? Let's take a look at the frontend.

Slide 25

Slide 25 text

BUILDING A FRONTEND WITH TYPESCRIPT Our principles: ▸ Functional style ▸ Tightly constrained inputs and outputs

Slide 26

Slide 26 text

PICKING A FRAMEWORK The ideal framework for a type-first UI would: ▸ Declaratively generate UI ▸ Describe visual components as pure functions of inputs

Slide 27

Slide 27 text

A TOUR

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

So, we have UI that takes tightly scoped types as inputs. What if we used our domain types as inputs to that UI?

Slide 31

Slide 31 text

BOOM. MATHEMATICALLY VALIDATED REPRESENTATION OF THE DOMAIN.

Slide 32

Slide 32 text

Design! IN YOUR SOURCE CODE!

Slide 33

Slide 33 text

AN ASIDE, ON FLEXIBLE COMPONENTS

Slide 34

Slide 34 text

COOL. SO, WHAT ABOUT THE BACKEND?

Slide 35

Slide 35 text

A backend's job is to gather and manipulate data.

Slide 36

Slide 36 text

LET'S CHECK IT OUT.

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

INSTANT. COMPILE-TIME. SYSTEM TEST.

Slide 39

Slide 39 text

YOUR TYPES ARE YOUR bones.

Slide 40

Slide 40 text

OKAY, SO. THIS DOESN'T MEAN THERE'S NO WORK INVOLVED.

Slide 41

Slide 41 text

WE'RE JUST SAVING OUR ENERGY FOR THE hard problems.

Slide 42

Slide 42 text

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 [email protected] See also: https://github.com/atomicobject/ts-react-graphql-starter-kit https://github.com/atomicobject/ts-workshop