Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JavaScriptures 4.2 - Local State

JavaScriptures 4.2 - Local State

Artsy Open Source

April 12, 2018
Tweet

More Decks by Artsy Open Source

Other Decks in Programming

Transcript

  1. Data is passed into a component as props, and components

    then pass that data to other components as props
  2. If you can't change the data that’s passed into a

    component, how does one manage state?
  3. UI interaction can be easily managed within a single class

    -- think, button toggles, show / hide, basic http list views
  4. `setState` can take you far, but problems begin to occur

    when complex UI interactions need to be managed across multiple components
  5. When component setState starts to manage App state and is

    scattered across a codebase it begins to feel suspiciously like MVC and becomes increasingly hard to scale
  6. “ It helps you write applications that behave consistently, run

    in different environments (client, server, and native), and are easy to test. ” https://redux.js.org/
  7. Not a framework, but an architecture for data-flow • Based

    on Flux • Implements a Unidirectional Data Flow
  8. Single source of truth “The state of your whole application

    is stored in an object tree within a single store.” What is Redux?
  9. State is read-only The only way to change the state

    is to emit an action, an object describing what happened. What is Redux?
  10. Changes are Made with Pure Functions To specify how the

    state tree is transformed by actions, you write pure reducers. What is Redux?
  11. Store • A plain object, this is our one true

    source • The provider of a universal state to your entire app
  12. Store • A plain object, this is our one true

    source, • The provider of a universal state to your entire app Actions • Centralized set of functions for manipulating data in the store • All actions return a plain object describing what happened
  13. export const changeAdminStatus = ({isAdmin}) => ({ type: actions.CHANGE_ADMIN_STATUS, payload:

    { isAdmin } }) export const actions = { CHANGE_ADMIN_STATUS: 'CHANGE_ADMIN_STATUS' }
  14. export const changeAdminStatus = ({isAdmin}) => ({ type: actions.CHANGE_ADMIN_STATUS, payload:

    { isAdmin } }) export const fetchUsers = () => { return async (getState) => { const users = await http.get(‘/users’) return { type: actions.FETCH_USERS, payload: { users } } } } export const actions = { CHANGE_ADMIN_STATUS: 'CHANGE_ADMIN_STATUS' FETCH_USERS: 'FETCH_USERS' } With the introduction of middleware...
  15. Store • A plain object, this is our one true

    source, • The provider of a universal state to your entire app Actions • Centralized set of functions for manipulating data in the store • All actions return a plain object describing what happened Reducers • Called with two arguments from the store: the current state tree and an action • Outlines the shape of an initial state
  16. export function appReducer (state = initialState, action) { switch (action.type)

    { case CHANGE_ADMIN_STATUS: return Object.assign({}, state, { isAdmin: action.payload.isAdmin }) default: return state } }
  17. Dispatch • The thread connecting the store/reducer/actions Middleware • Interrupt

    dispatched actions with libraries or your own functions
  18. • Backbone used for models • React components rendered inside

    Backbone parent views • Mixture of Backbone and React in UI components
  19. • Backbone used for models • React components rendered inside

    Backbone parent views • Mixture of Backbone and React in UI components • React components used Backbone’s set/get methods for all data mutations
  20. React and Backbone elements in same UI could have separate

    instances of shared data • React and Backbone lifecycles exist independently from each other • Listeners for Backbone ‘change’ events were scattered throughout app to trigger re-renders
  21. React and Backbone elements in same UI could have separate

    instances of shared data • React and Backbone lifecycles exist independently from each other • Listeners for Backbone ‘change’ events were scattered throughout app to trigger re-renders Props and onChange functions were passed down the entire component tree
  22. React and Backbone elements in same UI could have separate

    instances of shared data • React and Backbone lifecycles exist independently from each other • Listeners for Backbone ‘change’ events were scattered throughout app to trigger re-renders Props and onChange functions were passed down the entire component tree • Bug fixing is hard when tracking through deep layers of nesting
  23. React and Backbone elements in same UI could have separate

    instances of shared data • React and Backbone lifecycles exist independently from each other • Listeners for Backbone ‘change’ events were scattered throughout app to trigger re-renders Props and onChange functions were passed down the entire component tree • Bug fixing is hard when tracking through deep layers of nesting Data loss and views becoming out-of-sync is possible when components unmount
  24. React and Backbone elements in same UI could have separate

    instances of shared data • React and Backbone lifecycles exist independently from each other • Listeners for Backbone ‘change’ events were scattered throughout app to trigger re-renders Props and onChange functions were passed down the entire component tree • Bug fixing is hard when tracking through deep layers of nesting Data loss and views becoming out-of-sync is possible when components unmount • Rather than conditionally mounting components, we’d use jQuery to hide them
  25. One true source: Centralized data store is available to all

    components • A consistent source for editable data • But also can contain other information, like saved status or client errors
  26. One true source: Centralized data store is available to all

    components • A consistent source for editable data • But also can contain other information, like saved status or client errors Components that access centralized store re-render automatically when data changes • This operation can be memoized for highly performant update cycles
  27. One true source: Centralized data store is available to all

    components • A consistent source for editable data • But also can contain other information, like saved status or client errors Components that access centralized store re-render automatically when data changes • This operation can be memoized for highly performant update cycles Functions for mutating and saving data are consolidated to a centralized set of actions • Makes it easy to jump into a new codebase and see what’s possible
  28. Minimize props that are passed down component tree • By

    Connecting components, you can access the app’s store in them directly
  29. Minimize props that are passed down component tree • By

    Connecting components, you can access the app’s store in them directly Ability to log and track all calls to Redux actions in the console
  30. • Managing state with setState has become overly complicated •

    State is shared between components that don’t have a parent/child relationship
  31. • Managing state with setState has become overly complicated •

    State is shared between components that don’t have a parent/child relationship • State changes are reflected outside the component where they are triggered, or are paired with asynchronous functions
  32. • Managing state with setState has become overly complicated •

    State is shared between components that don’t have a parent/child relationship • State changes are reflected outside the component where they are triggered, or are paired with asynchronous functions • Following how your state changes is opaque, and a step-through/undo history is necessary to understand it
  33. • Managing state with setState has become overly complicated •

    State is shared between components that don’t have a parent/child relationship • State changes are reflected outside the component where they are triggered, or are paired with asynchronous functions • Following how your state changes is opaque, and a step-through/undo history is necessary to understand it • Props are passed down the component tree liberally, including through places they aren’t used