Skip to content

Instantly share code, notes, and snippets.

@rjz

rjz/pdx-reactjs-lightning-talks.md

Last active February 13, 2019 23:51
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rjz/497c6c3d8e6eea0cae85889d37481856 to your computer and use it in GitHub Desktop.
Save rjz/497c6c3d8e6eea0cae85889d37481856 to your computer and use it in GitHub Desktop.
Download ZIP
Lightning talks from the @pdxreactjs meetup on 2019-02-12.
Raw
pdx-reactjs-lightning-talks.md

PDXReactJS Lightning Talks

Lightning talks from the @pdxreactjs meetup on 2019-02-12.

A Better Approach to React Testing

Daniel Lemay - @dslemay (slides)

Let's talk about Enzyme

enzyme is Airbnb's testing library

  • Difficult to reason about (58 methods in the public API, lots of boilerplate)
  • Enzyme uses a wrapper (rather than the DOM)
  • Enables implementation-specific tests (are the tests broken or your inputs?)

Enzyme tests don't necessarily represent how your components will be used. They're brittle, and no-one wants to spend time updating tests instead of, say, actually adding value to a project.

And react-testing-library

@kentcdodds created react-testing-library out of frustration with Enzyme.

  • Wrapper for react-dom/test-utils that encourages testing "the way your components will be used."
  • API is simpler (render returns a bunch of assertions on the rendered component)
  • Renders into jsdom

Better testing experience: no touching implementation details, so more resilient against refactoring.

Officially recommended testing library (as of React 16.8)

React Architecture

Jack Toumey - @JackToumey

  • Shy away from complexity (it sounds difficult) - but adding extra structure (e.g. redux) can make code that's easier to follow, more maintainable
  • Data interfaces - type definition and methods on those types
  • Applications - have mini-applications (master, many slaves [sic]) and a bunch of reusable utilities
    • data interfaces are apps
    • graphical interfaces are, too

Goals

  • Good dev experience - fun, easy, short stack traces
  • Separate concerns between teams
  • Scalability .... over time, over compute, over network load

Solutions

  • Serialize, then deserialize. Need lots of interfaces separating lots of mini-apps
  • Organize by domain, not technology
  • REST bad (poor interfaces, hard to build good ones), GraphQL good (easy to split code, develop at scale)
  • SDL (the GraphQL sort, not the DirectMedia Layer sort) lets you write a concise schema and generate GraphQL resolvers. But boilerplate probably won't hold up at scale.
  • Redux bad (too complex, reactivity is hard), Apollo good (GraphQL interface, easy caching and reactivity; store built in)
  • CSS files bad (no conditionals), CSS in JS good (gives a universal feel to your app, and being in JS lets you use the JS tools e.g. to track down where styles are coming from. downside is bundle-size)

CSS in JS

Derek Hurley - @dzhurley

Code Sandbox.

Wanted to rewrite personal site in Next.js. They take care of lots of the heartache of the server-side. Also to use Emotion, as it's getting lots of buzz.

Wanted smooth transitions between routes. Next and Emotion make that easy. Next takes care of rendering CSS-in-JS server-side, also routing. Every time you navigate, Next knows how to fetch more JS for your new pages and it Just Works™.

Next is prescriptive: render site using App component; set Global for global styles, Nav for routing, and Component to define pages.

Emotion lets you provide properties to your CSS (e.g. injecting the pathname from a route when a user navigates).

Hooks

Jason Brown - @browniefed

State of the world

  • Stateless Functional Components (SFCs) - Rendering only (minimal logic)
  • Class Components - Includes state, implements lifecycle methods

Then hooks get released in v16.8, and there are suddenly a bunch of useX methods in React. React docs have a really good explanation, but let's see what they're about here.

Hooks

  1. Add state to functional component
  2. Less syntax generated w/ class polyfills (this is a few KB gzipped - not a ton, but does add weight)
  3. Easy to compose (they're just functions!)

Reusable logic across components (truly! Not mixins, which depended on inheritance).

Hooks look like magic. React knows what's being rendered, and as long as hooks are called in the same order it can maintain their order. The "magic" happens behind the scenes.

Composable: you can create custom hooks by tying other hooks together, e.g. useLocalStorage (not a hook) can put useState's API around an instance of localStorage.

Test like normal components -- react-testing-library (see above!) supports this.

Limitations

  • No conditionals - once the render happens, React hold the hooks in their original order. Don't change that!
  • Lots of foot-guns!
    • useState doesn't merge state or require objects, and returning the same state will cancel an update
    • useEffect is componentDidMount and componentDidUpdate (sort of).
      • Good place for mutations, side-effects, but improvements coming down the pipe will be better for data-loading. Don't useEffect for data-loading.
      • Runs after painting (DOM is already set)
      • Second argument (determines if effect is re-run / DOM should be updated)
    • useContext provides a context (saves the trouble of render props)
    • useRef grants access to elements or instance variables (e.g. a timer handle)
    • useLayoutEffect runs before painting (i.e., before useEffect) -- replacement for cDM and cDU
    • useImperativeHandle exposes a public API (e.g. focus()) on a functional component (e.g. so external components can focus() a component)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment