jasonrhodes

// these examples use thunks but the problem applies to most other redux async strategies

// action creator 1: get user
const getUser = async (id) => (dispatch) => {
  dispatch({ type: 'GET_USER_PENDING', payload: id })
  try {
    const result = await doAsyncThing(id)
    return dispatch({ type: 'GET_USER_SUCCESS', payload: result })
  } catch (error) {
    return dispatch({ type: 'GET_USER_FAILED', payload: error })

jasonrhodes

// higher order component creator
const withFun = (Component) => (props) => <Component {...props} fun='Injected Secret Value' />

// using the higher order component (with this pattern, you have to create a component, THEN wrap it in the HOC creator function)
const _MyComponent = (props) => <div><h1>{props.fun}</h1></div>
const MyComponent = withFun(_MyComponent)



// "render prop" using children

jasonrhodes

Jason Rhodes / Speaking and Writing CV

This is a list of links to slides, videos, and other information about tech talks I've given, as well as links to blog posts and articles I've written. They're in reverse chronological order. All of my slide decks can be found on my Speaker Deck profile, as well.

Blog Posts and Articles

• How to Draw an Owl with React: A Migration Story
• Getting Started with React: Angular Edition
• Easy Heroku-like git deployments with Dokku and Digital Ocean
• Hey Baltimore JavaScripters, What's Up? --> The start of CharmCityJs

jasonrhodes

What's new with React, 2018 edition

Slides: https://speakerdeck.com/rhodesjason/whats-new-with-react-2018-edition

Links:

• Fiber demo: https://claudiopro.github.io/react-fiber-vs-stack-demo/
• React 16 blog post (fragments, portals, error boundaries, fiber): https://reactjs.org/blog/2017/09/26/react-v16.0.html
• React 16.3 blog post: https://reactjs.org/blog/2018/03/29/react-v-16-3.html
• Dan Abramov's awesome JSConf Iceland talk about Async Rendering (Time Slicing/Suspense): https://www.youtube.com/watch?v=v6iR3Zk4oDY
• More from the React team re: async rendering: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html

jasonrhodes

// You can chain a list of this type of "chainable" http function with "callback hell"
chainA({ cb: (results) => 
  chainB({ results, cb: () => 
    chainC({ cb: (results) => 
      chainD({ results }) 
    }) 
  }) 
})

// But I want a helper with this API:

jasonrhodes

import { Route } from 'react-router-dom'

export default function Redirect({ to, from, ...rest }) {
  return <Route path={from} {...rest} render={({ location }) => (
    <Redirect to={{ ...location, pathname: to }} />
  )} />
}

jasonrhodes

/**
 * This file: https://github.com/facebook/react/blob/fb85cf2e9c52a4b2999144a89a6ee8256aec55c7/packages/react/src/ReactContext.js
 * if you remove the <flow> stuff and the "calculate changed bits" stuff, it appears to be
 * a function that, when called, returns an object literal with some weird circular references?
 *
 * How is this working / what am I missing here?
 */
export function createContext(defaultValue) {
  const context = {
    $$typeof: REACT_CONTEXT_TYPE,

jasonrhodes

Say you have a function that takes a single argument like this:

// return a string date that is "n" days before "right now"
function backInTime(n) {
  return subtract(new Date(), n, 'days').toString();
}

So if you call this (on Thurs, Feb 22) a few times in a row (pretending each one takes a full second to run) you would get:

jasonrhodes

#!/usr/bin/env bash

get() {
  sudo systemsetup -gettimezone
}

set() {
  sudo systemsetup -settimezone $1
}

jasonrhodes

The Rules

1. Action creators must return something "simple". A plain object, a simple function call, or at worst: a thunk.
2. Internal API call logic must be encapsulated and abstracted away out of sight
   • authorization token decoration
   • refresh and retry logic
   • logout on fail logic
3. External API calls are subject to the same async processing as internal API calls (pending, success, fail events at minimum)
4. Internal API results trigger notifications for success and fail, according to a limited set of rules
5. Calls can be correctly chained (i.e. failures exit the chain), with access to previous call's response