3 ms·

Love react hooks (along with TypeScript) Just for the sake of readability. Easier to grok. Perhaps all along though classes I had were just making inefficient/

by tony 7y ago

Love react hooks (along with TypeScript) Just for the sake of readability. Easier to grok. Perhaps all along though classes I had were just making inefficient/incorrect use of lifecycles though. React's lifecycles still mystify me. I can't tell where and how renders come from. If there was an easier way to trace it, it'd be nice. I'm making use of `React.forwardRef` and `useImperativeHandle` also. It's neat because you can forward information from a inner component for "direct" access in its parent. (https://reactjs.org/docs/hooks-reference.html#useimperativehandle https://reactjs.org/docs/hooks-reference.html#useimperativeh...) My pitfall is variables inside callbacks that used to be "live" are stale upon invocation. So if you have a complicated components where you fishline callbacks, it doesn't behave the same. In my case, the solution was to wrap the callbacks in `useEventCallback` https://reactjs.org/docs/hooks-faq.html#how-to-read-an-often-changing-value-from-usecallback https://reactjs.org/docs/hooks-faq.html#how-to-read-an-often...

acemarke 7y ago
Out of curiosity, what about renders confuses you? I can try to summarize: - React stores an internal tree of bookkeeping objects ("fibers") that store info on what component is being rendered at each location in the tree - Any state update function (class component `setState()`, `useState` setters, `useReducer` dispatch) queue a re-render pass, and mark this component as needing an update - During a re-render pass, React walks that fiber tree to find components that need to render, either because they're marked as dirty, or because the parent re-rendered. For function components, React calls `funcComp(fiber.props)`. For class components, it attaches `instance.props = fiber.props`, and then calls `instance.render()` - Class component lifecycles and function component lifecycles are called at appropriate points during that render pass Hmm. Re-reading, are you asking how to determine what _causes_ a given render pass? That one's more opaque. However, the new React DevTools 4.0 will at least tell you why each component re-rendered during a specific pass.
- swyx 7y ago
  i believe they dont even want people fixated on when and why things rerender. write your code right (with effects and suspense boundaries in the right places) and let react figure it out. not sure if they'll succeed in making people not care about optimizing for number of renders vs overall speed tbh. we're so used to one way of thinking about perf.

by tony 7y ago

acemarke 7y ago

Out of curiosity, what about renders confuses you? I can try to summarize: - React stores an internal tree of bookkeeping objects ("fibers") that store info on what component is being rendered at each location in the tree - Any state update function (class component `setState()`, `useState` setters, `useReducer` dispatch) queue a re-render pass, and mark this component as needing an update - During a re-render pass, React walks that fiber tree to find components that need to render, either because they're marked as dirty, or because the parent re-rendered. For function components, React calls `funcComp(fiber.props)`. For class components, it attaches `instance.props = fiber.props`, and then calls `instance.render()` - Class component lifecycles and function component lifecycles are called at appropriate points during that render pass Hmm. Re-reading, are you asking how to determine what _causes_ a given render pass? That one's more opaque. However, the new React DevTools 4.0 will at least tell you why each component re-rendered during a specific pass.

swyx 7y ago
i believe they dont even want people fixated on when and why things rerender. write your code right (with effects and suspense boundaries in the right places) and let react figure it out. not sure if they'll succeed in making people not care about optimizing for number of renders vs overall speed tbh. we're so used to one way of thinking about perf.