Declarative UIs with React

Transcript

1. Declarative UIs with ReactJS @fknussel
2. React is: • A JavaScript library for building user interfaces. • Often referred to as the “V” in MVC
3. Why choose React • Proven at scale • Active OSS community • Easy to learn • Learn once, write anywhere
4. Core Features • Virtual DOM • Componentised architecture • Unidirectional data-flow
5. A React application is divided up into components = Idempotent functions that take in the current state of your application and return the UI of your application.
6. view = f (state)
7. In CS, an idempotent operation is one that has no additional effect if it is called more than once with the same input parameters. • Removing an item from a set is an idempotent operation on the set. • The abs() function is idempotent because abs(abs(x)) = abs(x) for all x .
9. JSX • Syntactic extension to JavaScript • Completely optional ◦ see https://reactjs.org/docs/react-without-jsx.html • Used for templating • This is what JSX compiles down to… ◦ see online Babel compiler
11. Declarative views make your code more predictable and easier to debug and test, and also forces you take your state out of the DOM ⇒ single and trustworthy source of truth
12. Composition We build our apps by composing components.
14. Unidirectional Data Flow Data flows top-down, while actions are hoisted up.
16. The good ol’ Notification widget example
17. Defining transitions based on the different states Imperative UIs
27. Adding a single new state will add a whole new bunch of transitions that can occur.
29. O(N(N-1)) From any state you can transition to n-1 other states
30. “Controlling complexity is the essence of computer programming.” — Brian Kernighan
32. Defining states, not transitions Functional UIs
33. Stateful, mutable UI • Immutable views • Pure render functions • One-way data flow
34. Imperative UI: define transitions Functional UI: define states
36. Effectively what we are doing is rebuilding the DOM for every change...
37. View is recreated each time… but isn’t that slow? Enter… Virtual DOM
38. • Fast / Lightweight Nodes ◦ Created and thrown away with every render • Avoid Layout Thrash ◦ Reading from the DOM can force a reflow ◦ i.e. if we set a value and read from the DOM it might force the browser to recalculate the layout of a page, which is an expensive operation ◦ Ift doesn’t happen in React b/c of: • Queue Updates ◦ Batching DOM read/write operations ◦ Executed after reconciliation
42. • React's Design ◦ Simple component model for rendering the view layer ◦ Conceptually re-render the whole app on every update ◦ Avoid O(N²-N) state transition complexity (avoid writing transitions) • Virtual DOM ◦ Lightweight descriptors that specify the desired render tree • Reconciliation ◦ Calculates a minimal set of changes to apply to the DOM
43. Credits: • https://www.infoq.com/presentations/react-reconciliation • https://www.slideshare.net/floydophone/react-preso-v2 • https://www.youtube.com/watch?v=GW0rj4sNH2w Courses, videos and further reading: • https://react.holiday/ • https://reactforbeginners.com/ • https://egghead.io/courses/the-beginner-s-guide-to-reactjs • https://btholt.github.io/complete-intro-to-react/ • https://tylermcginnis.com/imperative-vs-declarative-programming/ • https://egghead.io/courses/advanced-react-component-patterns