Share this page!

Enter URL or ID to Unroll

You can paste full URL like: https://x.com/threadreaderapp/status/1644127596119195649
or just the ID like: 1644127596119195649

How to get URL link on X (Twitter) App

  1. On the Twitter thread, click on or icon on the bottom
  2. Click again on or Share Via icon
  3. Click on Copy Link to Tweet
  4. Paste it above and click "Unroll Thread"!
  5. More info at Twitter Help
Andrew Clark Profile picture
Andrew Clark
@acdlite
@reactjs core team, @nextjs, @vercel. He/him. Hi!
Feb 23, 2023 • 9 tweets • 3 min read
I really don't mean to be too dismissive of the enthusiasm around signals. I just prefer to imagine a world where the main thing you think about when building components is something other than optimizing update performance. To me that was central to the original pitch for React: you don't have to think about how updates flow through your UI anymore! Just rerender the whole thing and we'll make it fast enough. I think that bet has paid off so far, even if there's more to do to make it better.
Jan 23, 2023 • 7 tweets • 2 min read
If you use React, you should be using a React framework. If your existing app doesn't use a framework, you should incrementally migrate to one. If you're creating a new React project, you should use a framework from the beginning. Your React framework of choice should have built-in solutions for data fetching, routing, and server rendering. Frameworks don't treat these as independent concerns — they provide deeply integrated solutions that are easy to use and result in excellent performance out of the box.
Jul 1, 2021 • 16 tweets • 4 min read
Includes a great explanation of the limits of cooperative concurrency!

The post asserts the only viable solution is to move tasks into workers. Since React 18 does include a cooperative renderer, I'll share how we solved the problems @DasSurma identifies
(This doesn't mean the React team isn't interested in workers — we are! But we're tackling main thread concurrency, too, since that's where the vast majority of application code lives today.)
Jul 1, 2021 • 5 tweets • 1 min read
Fuck it. I bought an espresso machine. Someone please talk me out of it, there's still time to cancel the order
Jun 29, 2021 • 5 tweets • 1 min read
That's cool and all but: stacked PRs when? copilot.github.com @github If I could stack a PR... that would really make me happy. Help a guy out?
Jun 10, 2021 • 14 tweets • 5 min read
Here's a side story about the two big refactors we did last year:

They touched almost every core module. They were inherently risky so we needed to gradually roll them out. But we didn't want to block other features.

So I copy-pasted the whole codebase!

If you ever see files in the React repo that end in `.new` or `.old`, that's what that is: to this day, we maintain two copies of all our core modules (the "reconciler").

The forks live side-by-side in the same codebase. Not in separate branches.

github.com/facebook/react…
Jun 9, 2021 • 16 tweets • 7 min read
Seconded. Rick has made a huge impact in the last year since joining the team. We've given him several really tricky projects and I'm incredibly impressed by how he's taken ownership and seen them through.
Also can't thank @bvaughn enough. He did some really complex, grueling work on our effects implementation last year to unblock a public alpha. (Oh, and he also happens to design and build React DevTools. Nbd.)
Dec 13, 2020 • 5 tweets • 1 min read
You should complete the easy stuff first, and the hard stuff later, because until the hard stuff is done, it’s better to ship something than nothing.

You should complete the hard stuff first, and delay an initial release, because the easy stuff might not be viable without it. Do the hard stuff first because the easy stuff might lead you down a dead end and by the time you realize you’ll need to start over.

Do the easy stuff first because it might reveal the hard stuff is unnecessary.
Sep 3, 2020 • 8 tweets • 2 min read
Maybe an unpopular opinion, but I actually think the React team is very good at accepting criticism and synthesizing it into their roadmap without overreacting to every complaint or trend or fad.

I do agree we could do a better job onboarding new contributors. In my ideal world, we'd have lots of non-FB contributors working full time on React and steering its direction.

However, as it is, we have a hard enough time onboarding contributors *within* FB. Not saying the status quo is acceptable, just that it's a hard problem.
Jun 1, 2020 • 8 tweets • 2 min read
There's a real debate about whether Facebook should fact-check, suppress, or de-platform demagogic politicians. Personally, I think we should be doing at least the first two.

But to me, there's a deeper issue: Facebook is breaking society, and we're not doing enough to fix it. Trump's incendiary posts are a problem. But absent Trump, your feed would still be overrun by inflammatory clickbait from distant relatives and that weird kid from freshman biology class.

This is a harder problem, and it infuriates me how slow Facebook has been to address it.
Apr 29, 2020 • 8 tweets • 3 min read
I like GitHub as a platform, but as a code review tool, it's not designed for my workflow at all.

This is what most of my PRs look like: To support stacked diffs properly, GitHub would also have to abandon their hostility toward rebasing.

Here's the UI that Facebook's internal code review tool gives you when you update a "diff" (PR). All the previous versions are still available:
Nov 19, 2019 • 13 tweets • 3 min read
When it comes to functional purity, everyone’s all about avoiding external writes. You don’t hear so much about avoiding external reads. But both are required for purity, and the reads are arguably harder to avoid.

Something for y’all to think about. I think it’s because “side effect” is catchy and easy to grasp but there’s no similar catchy term for accessing an external mutable data source.

So instead they both get lumped under the term “effects.”
Nov 14, 2019 • 6 tweets • 1 min read
Redux (complicates things) People think all my posts are shitposts (most are extremely sincere, Actually) but if that were true I would tweet about Redux all the time
Dec 6, 2018 • 6 tweets • 2 min read
I've been trying to write about Concurrent React, but I'm finding it difficult because everything is so interconnected.

So I'm starting from scratch with a new approach: write all the topics down, flesh out the details, then break and edit the result into managable pieces. These are really rough outlines, mostly notes for myself so I don't forget later.

I'm finding it hard to query my brain for all the interesting things. If there's something you'd like to know about Concurrent React or Suspense (or React in general), let me know!
Aug 2, 2018 • 7 tweets • 2 min read
Redux is a stupid fucking event emitter with a disproportionately excellent ecosystem of tools built on top of it. I wonder what the opportunity cost of that ecosystem is; imagine if those tools were built on top of something other than a stupid fucking event emitter, like React. This tweet has been sitting in my drafts for months, yolo
Jun 14, 2018 • 4 tweets • 1 min read
How to Code Split with React Suspense

Coming soon to open source.

We're already shipping a version of this to Facebook employees. The code is sooo much nicer than before. Fun fact: the same API works in sync mode, too. The difference is that we have to fallback to the spinner immediately, as if `delayMs={0}`. But you still get the nicer programming model.
May 19, 2018 • 5 tweets • 2 min read
When reviewing a PR, it’s essential that you leave a comment. Any comment. Even the PR looks great and you have no substantial feedback, find something trivial to nitpick or question. This communicates intelligence and mastery, and is widely appreciated by your colleagues. Automated code quality tools like @PrettierCode and @geteslint can sometimes make this difficult, but with a little creativity, no PR is immune to your scrutiny.