React v18.0 has broken ground by introducing a long-awaited feature: Concurrency! Unfortunately, despite a deluge of resources explaining how to use it, explanations of how it works are sparse. As it is a low-level feature, it’s not critical to understand React’s idea of concurrency, but it doesn’t hurt!

JavaScript runs in a single-threaded environment with an event loop, an architecture that is very easy to reason about. It’s a continuous loop executing incoming work. Synchronous work runs immediately; asynchronous work runs when there is no synchronous work to left to perform. This design implies that performing synchronous work is a Big Deal: for every continuous moment it runs, the event loop cannot perform any work – none!

Before the introduction of contexts and hooks in React v16.8, Higher-Order Components (or HOCs for short) were a common sight. Today, it is an under-used pattern. While the concept presents infinite possibilities, practical applications should be limited to transparently adding wrappers or logic.

If you use GitHub Actions for deployments in a “push to master, deploy to prod” sort of flow, you’ve likely wanted to avoid deploying conflicting refs. By default, GitHub Actions will want to run a deployment for every commit as soon as you push it. Concurrency groups help, but it requires a bit of creativity to get it running smoothly.

Airbnb has an internal GraphQL server called Viaduct. A feature of Viaduct is that for any response it returns, it adds a __typename for every object which corresponds to the name of its type.

Is it possible to remove them without rewriting the type definition by hand?