Lightning talks from the @pdxreactjs meetup on 2019-02-12.
Daniel Lemay - @dslemay (slides)
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.
@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)
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
- Good dev experience - fun, easy, short stack traces
- Separate concerns between teams
- Scalability .... over time, over compute, over network load
- 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)
Derek Hurley - @dzhurley
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).
Jason Brown - @browniefed
- 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.
- Add state to functional component
- Less syntax generated w/
class
polyfills (this is a few KB gzipped - not a ton, but does add weight) - 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.
- 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 updateuseEffect
iscomponentDidMount
andcomponentDidUpdate
(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)
- Good place for mutations, side-effects, but improvements coming down
the pipe will be better for data-loading. Don't
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., beforeuseEffect
) -- replacement for cDM and cDUuseImperativeHandle
exposes a public API (e.g.focus()
) on a functional component (e.g. so external components canfocus()
a component)