I wonder if our early messaging about Concurrent Mode should have been focused on mounts rather than updates. Some of the conversation I’m seeing assumes we could just “do less work” which is not an option for rendering *new* subscreens — where granular rerendering doesn’t help.
This depends on the app — some apps, like dataviz, almost exclusively do “updates”. So dataviz example, while effective visually, may have been a misdirection. In consumer apps a lot of the interactions we want to make smoother are mounts — like switching tabs or infinite scroll.
There’s also a question of responsibility. We consider what happens when you have hundreds of components that all run a little bit of code *our* responsibility. Userland code then dwarves library overhead in CPU time. We can’t just wash our hands and say “don’t write slow code”.
Granular rerendering is certainly useful (and disproportionally useful for dataviz and graphical editors). There are several ways you can solve it. The problem with many popular solutions is that they preclude solving the mounts. This is why we start from the other end.
There are many features that your library gets if you solve non-blocking mounts. Like pre-rendering the contents of a hidden tab optimistically without blocking the initial paint and delaying user input. Or rendering long lists in visually intentional chunks.
I don’t care if the library authors of today see this as a problem worth solving. But I want to inspire the authors of libraries of tomorrow to at least consider it. We have several tabs, each has a deep tree inside, each layer has a fixed user code cost. Now make it responsive.
Maybe this problem alone by itself isn’t worth your effort. It is hard. But if you spend enough time on it, you might discover that other areas — animations, data fetching, hydration, code splitting — now allow new solutions you couldn’t consider before. If your model allows it.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Dan Abramov

Dan Abramov Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @dan_abramov

18 Aug
Apparently this needs to be said but you can absolutely start with React and skip “JS fundamentals” IF YOU WANT. You’ll be confused about some things for sure (!), but for some people (incl. me) getting something on the screen is the only thing sustaining the initial interest.
Be wary of advice like “I learned it in the wrong order, so don’t repeat my mistakes”. It reeks of survivor bias. Those people *did* end up learning both, right? Maybe if they approached it from the other end they wouldn’t even finish it and switch to something else.
Learning is not linear. You can “start anywhere” and branch out. It is much more important to be learning effectively (e.g. learn to recognize when you have a gap instead of trying random guesses until it works, and learn to ask the right questions).
Read 10 tweets
5 Aug
If you use react-hot-loader, now is a good time to remove it and try Fast Refresh (and its webpack plugin by @pmmmwh). RHL is extremely brittle, relies on many hacks, and has caused countless issues. It served its purpose and its time is due.
RHL was my first popular personal project. At the time, few people took it seriously. Many thought it’s a silly gimmick. I was genuinely sure that it wouldn’t catch on in the community, and that people would keep reloading their app on every JS change.
I was wrong in that, as gradually the ability to edit component code in place has become the norm and the expectation. I’ll take some credit for that. However, as React moved to ES classes and later proposals like class properties, it has become harder and harder to support.
Read 6 tweets
3 Aug
@nomadtechie I think there’s a few questions here that we need to split apart.

1. Is an event system useful (as opposed to just attaching events on nodes)
2. Does it have to wrap native event objects into custom ones
3. Are React's event polyfills still relevant
@nomadtechie The answer to (1) is yes IMO. Event system uses delegation — i.e. instead of a listener per node, we attach it at the top. This is useful for features we care about (like ability to “record” and “replay” events after hydration). Less work on mount. Solves some edge cases too.
@nomadtechie The answer to (2) is probably no and we can probably use native events there. We’re already removing pooling in 17 so they’re very close. There’s some normalization we still do but it’s probably not as important these days or could be polyfilled separately from React.
Read 6 tweets
10 Jul
@wycats @garybernhardt Oh no, *this* case definitely sucks and is definitely something we often run into. The plan is to have a compiler do this automatically so that it comes up much less often. Unfortunately we haven’t had time to invest into it yet.
@wycats @garybernhardt The other recourse is simply reduce the need for useEffect. I don’t think it’s really the best solution for this case but sometimes structuring code without it is awkward for other reasons. Which we should address.
@wycats @garybernhardt I think this case is a good example of where reactivity is not the right tool. There’s already an explicit signal for when this function should run — the user clicks a button and AJAX response come back. Rederiving this signal through change notifications is lossy by definition.
Read 4 tweets
9 Jul
@tannerlinsley That’s exactly what I’m saying here. Suspense *as a feature* doesn’t do much, and is already available (it even works with caveats in stable). The point isn’t that feature but the whole picture — reading data anywhere in the tree without ceremony. That requires a cache.
@tannerlinsley When we say “Suspense for data fetching” we don’t mean “the Suspense component”. That’s been done over a year ago. We mean an integrated and flexible solution that lets you write code in that paradigm.
@tannerlinsley This solution includes: a way to read data anywhere in the tree, a consistency guarantee (if parent and child both read some data for new ID, you don’t show old+new mixed up), a cache layer to avoid waterfalls, an invalidation strategy, plus a code splitting integration.
Read 16 tweets
24 Jun
You NEED to watch Dark. I don’t know how to emphasize it. It is a VERY GOOD SHOW that is soooo slept on in the US.
It is a German show on Netflix. You need to enable the subtitles (the English dub is pretty bad and destroys the atmosphere). So what? It’s like watching Miyazaki, you can manage it!
The first thing you’ll notice is similarities with Stranger Things in the plot start (small town, kid missing, mysterious power plant). That’s a red herring, IGNORE THAT. This show isn’t similar at all. I like both ST and Dark but they’re polar opposites in ideas and atmosphere.
Read 34 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!