React gsg presentation with ryan jung & elias malik
Download as PPTX, PDF0 likes105 views
React is a client-side JavaScript library for building user interfaces that is made and open-sourced by Facebook. It uses a virtual DOM for fast rendering and reusable components to build up the UI. Components can have their own state that causes re-rendering when updated. Events are handled through callbacks. JSX allows writing HTML-like code mixed with JavaScript. Managing state across complex apps with many interacting components can be challenging. Flux and Redux address this with a single source of truth store and reducer functions that update state immutably in response to actions. Side effects like API calls require middleware like thunks, sagas, or API-specific middleware to isolate impure logic from pure reducers.
React gsg presentation with ryan jung & elias malik
- 1. React
- 2. What is React? • Client-side library made and open-sourced by Facebook • Much simpler than Angular (fast learning curve) • Main goal is to be fast, scalable, and simple • React Native allows you to port over code to native iOS or Android apps
- 3. Why Would You Use React? • Fast Learning Curve • Reusable Components which manage state • Ability to use JSX which reduces risk of XSS • Abstraction o View in MVC as opposed to client-side MVC o Use Flux/Redux as single source of truth
- 4. React Basics – Virtual DOM / Components • Virtual DOM o React keeps an abstraction of the DOM; when changes are made, it will only re-render the elements that were changed, not the entire DOM o Makes it very fast from a performance perspective • Components o React allows you to create your own HTML elements and then define logic and state variables for these elements o 2 key methods to know: o React.Component: o Allows us to define new Components o Must have render() method o ReactDOM.render: o Lets us place Component in DOM
- 5. React Basics - State • As noted, each Component maintains its own set of variables which programmer defines • We can set and get these state variables; when we set them, it causes the Component to re-render • We will talk about this more later, when we discuss Redux
- 6. React Basics – Events and JSX • Components have lifecycle methods and event-based methods that will update state and re-render • For events (such as onClick or onSubmit), we access value through event.target.value -> pass this to child components if necessary, and then update state • JSX o React allows you to write HTML-like code mixed with JS to define how to render or manipulate Components
- 7. Components can have state A complex UI usually introduces dependencies between components Parent -> Child dependencies are easy Child -> Parent and Sibling dependencies are harder The State Management Problem
- 8. The State Management Problem
- 11. Library written by Dan Abramov (@gaeron) Built on a reducer abstraction Redux: Reducer + Flux
- 12. Redux: Reducer + Flux Reducer Action Reducer Action State State State Action ...
- 13. Redux: Reducer + Flux Flux Redux Update logic in stores Update logic in reducers Multiple stores Single store, multiple reducers Multiple state trees Single state atom Easy state reconstruction
- 14. Redux: Reducer + Flux
- 15. Redux reducers should be pure functions This makes testing Redux based code really easy, right? ...But how do we handle side effects? AJAX calls Web Sockets Integrating 3rd party libraries Side Effects with Redux
- 16. New State Side Effects with Redux: Middleware Middleware 1 Middleware 2Action ... Side effect? Dispatch action? Reducer Store Store Side effect? Dispatch action?
- 17. Many different solutions exist, variously opinionated Look at three different middlewares, and their impacts on testing: redux-thunk (@gaeron) redux-api-middleware (@agraboso) redux-saga (@yelouafi) Standard example: making an API call Side Effects with Redux: Middleware
- 18. Side Effects with Redux: Thunks Redux-thunk allows action creators to return functions Those functions can be impure, and also dispatch other actions Generalised solution to side effects, can be used for API calls
- 19. Side Effects with Redux: Thunks How do we test this? Action creators no longer pure functions Could mock Redux store and API call?
- 20. Middleware that deals only with making API requests. Many existing examples. Will use “redux-api-middleware” as example. Side Effects with Redux: API middleware
- 21. All API-related side effects isolated in (fully tested!) middleware Only need to check: Correct actions are being created Payload correctly processed Side Effects with Redux: API middleware
- 22. Side Effects with Redux: API middleware
- 23. Side Effects with Redux: Sagas Warning: Can be overkill for your app Significant additional abstraction Additional learning curve
- 24. Side Effects with Redux: Sagas Generators: May be familiar from other languages (e.g. Python) Allow function execution to be paused Allow information to be passed in and out
- 25. Side Effects with Redux: Sagas
- 26. Side Effects with Redux: Sagas
- 27. Side Effects with Redux: Sagas Question: So what? Added additional complexity, what have we won? Answer: Further decoupling of components Declarative actions Complex sequences of effects Easier testability of those complex sequences
- 28. Side Effects with Redux: Sagas
- 29. Side Effects with Redux: Sagas
- 30. Side Effects with Redux: Sagas Utilise helper functions from redux-saga for: Delays Debouncing Throttling Dynamically creating new sagas Cancelling existing sagas
- 31. Summary Thunks Specific Middleware Sagas General & flexible Allows building focussed API Powerful & flexible Testing requires mocking Small learning overhead Significant learning overhead Logic in action creators Easy testing Easy testing Suitable for smaller or simpler apps Suitable for most apps Suitable for large & complex apps
- 32. Thank You Elias Malik elias@foundersandcoders.com Github: @eliascodes
Editor's Notes
- #8: A React app consists of a component tree. Each component can have a child or a parent, and maintain own state. In apps with a relatively complex UI, there will usually be dependencies between the states of various components. Parent-child dependencies, easy. React provides solution: props More complex case: sibling dependency; state of a component depends on another not directly above it in the component hierarchy.
- #9: Used to often end up in situations like this. Dependencies are managed ad-hoc, components are coupled & hold references to each other. Example: user button click should update notification bar state This is problem, what is solution?
- #10: Facebook's answer to the state management problem Stores manage and reconcile state for a given _domain_ (e.g. UserStore, MapStore) Actions describe changes Dispatcher sends actions to all stores Views subscribe to store Uni-directional data flow Why is that good? Decouples components from each other. All now only depend on the store
- #11: End up in situation like this Only one store here for clarity. Cleaner, and not every component needs to subscribe to the store. So that’s Flux, but this talk isn’t about Flux, it’s about Redux.
- #12: Inspired by Flux, along with many other patterns; like those used in Elm and Om (ClojureScript) Built on a reducer abstraction Anyone use reduce regularly? Reducer is just a function; takes old state, and a new piece of information, returns new state Applied to collections of items
- #13: Key insight of redux is to view sequences of actions as a collection in time, which can be reduced over. Same structure as reducing array of elements to single element Just that in redux, the reduction operation is never complete, because new actions can be dispatched all the time.
- #15: So after implementing redux, you might end up with code that looks like this Action creator, reducer, component
- #17: Middleware intercepts actions Hold references to store Can hold arbitrary code, so good place to isolate side effects Can have early returns from middleware
- #18: Look at redux-api-middleware to illustrate focussed API of a middleware that is intended for specific purpose
- #19: Pros: > general > lightweight > sufficient for most small React apps Cons: > Inconsistent action creator return types > Tend to put a lot of logic in action creators
- #20: Explain test… This is OK, but lots of mocking is (1) annoying, (2) code smell: too much coupling / mixing of concerns Nonetheless, thunks are adequate solution for many
- #23: Explain test… This is easier to test that the equivalent thunk code. Having a specific middleware focussed on isolating one class of side effect is a useful pattern in general. Also used for websockets, I’ve used it when integrating 3rd party libraries into a Redux app
- #27: So what is a saga? A saga is just a generator that yields objects to the redux-saga middleware. These objects are instructions for the middleware. They come in two types: watcher sagas and worker sagas. Watchers listen for dispatched actions, while workers react to them. You can think of these sagas as daemons, or long-running processes in your app, that listen for changes. Explain example...