React Fundamentals - Jakarta JS, Apr 2016

Slide 1

Slide 1 text

REACT FUNDAMENTALS JAKARTA JS

Slide 2

Slide 2 text

Simon Sturmer : @sstur_ CTO / Fouder - KodeFox

Slide 3

Slide 3 text

WHY REACT? Part One

Slide 4

Slide 4 text

WHAT IS REACT? ▸ So you've heard the hype, but what is React? ▸ React is an opinionated View library. ▸ It is a fundamentally different way to build UIs. ▸ It leads to thinking in terms of pure functions and immutability and other good practices.

Slide 5

Slide 5 text

WHY REACT? ▸ Why are so many top companies choosing React? ▸ Netﬂix, Yahoo, Apple, AirBnB, WhatsApp, CloudFlare, Dropbox, Instagram, Twitter, Uber, WordPress even SaleStock Indonesia ▸ Performance, Testability, Code Reuse ▸ Developer Experience.

Slide 6

Slide 6 text

WHY REACT? ▸ How is React different from Angular/Ember/etc? ▸ Everything is a component. ▸ A component is a pure function of application state. ▸ Components can be reused, composed to create other components, isolated for testing. ▸ UI is easy to reason about as state changes over time.

Slide 7

Slide 7 text

REACT IS A BUSINESS DECISION, NOT JUST A TECHNOLOGY CHOICE!

Slide 8

Slide 8 text

REACT AS A BUSINESS DECISION ▸ Fewer, more versatile software engineers! ▸ Same dev team! Web, iOS, Android, Desktop ▸ Improved Testability, Reliability ▸ Performant by Default ▸ Real Code Reuse ▸ Velocity: shorten the edit-reload cycle; less time debugging ▸ Future proof: As your software evolves, replace individual components.

Slide 9

Slide 9 text

WHY BUSINESSES STILL CHOOSE ANGULAR/EMBER? ▸ New tech can be overwhelming. Where to start? ▸ How to train your dev team? ▸ Some have large, legacy code-bases with a lot of resources invested.

Slide 10

Slide 10 text

HOW IS REACT DIFFERENT? Part Two

Slide 11

Slide 11 text

WHAT PROBLEM DOES REACT TRY TO SOLVE? ▸ App state changing over time is hard to reason about. ▸ UI components get out of sync with each other and it's hard to debug. ▸ When changes happen, we have to reach deep into our view and mutate objects.

Slide 12

Slide 12 text

SHARED MUTABLE STATE IS THE ROOT OF ALL EVIL Pete Hunt, React.js Conf 2015 REACT + REDUX GIVES YOU IMMUTABLE STATE

Slide 13

Slide 13 text

REMEMBER THE OLD DAYS? ▸ Server-side Rendering ▸ Generating HTML views was easy! ▸ Why? … because we had the full application state at one moment in time (a snapshot) ▸ All we have to do is query stuff and generate HTML from that stuff. ▸ When an action happens, re-generate the entire view!

Slide 14

Slide 14 text

SERVER-SIDE RENDERING

Slide 15

Slide 15 text

SPRINKLING JS ON TOP ▸ Web apps slowly started doing more client-side ▸ DOM Manipulation: jQuery ▸ Client-side templating: mustache, handlebars ▸ Must wire-up events every time you generate new DOM ▸ Still need to manipulate the DOM!

Slide 16

Slide 16 text

EVENTS UPDATING VIEW

Slide 17

Slide 17 text

THE PROBLEM: ▸ There's way too much complexity around keeping your app in a consistent state. ▸ It's almost impossible to reason about. ▸ The bookkeeping makes for a poor developer experience.

Slide 18

Slide 18 text

THE SOLUTION: ▸ We never had that problem with server-side rendering! ▸ … because we just re-generated the entire view when a piece of state changed (url change). ▸ Can we do the same thing client-side?

Slide 19

Slide 19 text

CLIENT-SIDE FULL RE-RENDER

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

EVENTS UPDATING STATE

Slide 22

Slide 22 text

THAT'S EXACTLY HOW REACT WORKS.

Slide 23

Slide 23 text

VIEW IS A FUNCTION OF STATE: ▸ This means you can reason about your view just like you used to do with server-generated views. ▸ Your view is a deterministic function of your state.  (the same state will always produce the same view) ▸ Even if you serialize that state, save it to disk and restore it next week.

Slide 24

Slide 24 text

MORE EXCELLENT  THINGS WILL FOLLOW Once you start down this path…

Slide 25

Slide 25 text

YOU START DISCOVERING BONUS STUFF LIKE: ▸ Trivial undo/redo ▸ Easy hot-reloading during development ▸ Atomic/Optimistic updates ▸ Imagine if an HTTP request fails, you just load a previously stable state ▸ Time-travel debugging ▸ Imagine stepping back in time through your app state

Slide 26

Slide 26 text

LET'S LOOK AT  SOME REACT CODE…

Slide 27

Slide 27 text

REACT VERSION OF PREVIOUS EXAMPLE

Slide 28

Slide 28 text

EVENTS JUST UPDATE STATE!

Slide 29

Slide 29 text

…but there are

s in your JS!

Slide 30

Slide 30 text

IN REALITY IT WILL LOOK MORE LIKE THIS:

Slide 31

Slide 31 text

REACT ELEMENTS ▸ That stuff is JSX and it’s really incredible ▸ It looks weird at ﬁrst, but it is just [optional] sugar. ▸ JSX: ▸ Concise Syntax ▸ Static code analysis ▸ Directly compiles to JS

Slide 32

Slide 32 text

COMPOSITION OF COMPONENTS ▸ You build view components from other view components ▸ This is extremely powerful. ▸ Beneﬁts: ▸ Code Reuse ▸ Separation of Concerns ▸ Clean layers of abstraction

Slide 33

Slide 33 text

React leaves it up to you to separate concerns however you like.

Slide 34

Slide 34 text

MOST PEOPLE HAVE: ▸ Presentational components: ▸ Purely for layout/styling ▸ CSS designers can work on these ▸ Container components: ▸ Know about data structure and logic ▸ Don’t know anything about layout/styling

Slide 35

Slide 35 text

So what's the price you pay for using React?

Slide 36

Slide 36 text

REACT DRAWBACKS: ▸ Some setup complexity. Choices can be overwhelming. ▸ A moderate learning curve ▸ React will change the way you think about your UI. This takes some getting used to. ▸ Rapidly evolving ecosystem.

Slide 37

Slide 37 text

VASTLY OUTWEIGHS THE COST. But what you get in return…

Slide 38

Slide 38 text

DEVELOPER EXPERIENCE ▸ Move fast: shorten the edit-reload cycle; spend less time debugging ▸ Write testable code! ▸ Iterate with conﬁdence and build more reliable software. ▸ Learn once, write anywhere ▸ Web, iOS, Android, Mac/Windows, even console apps

Slide 39

Slide 39 text

: @sstur_ https://kodefox.com Simon Sturmer Thanks!