Joe Savona

The description: “This PR adds <feature> and unit tests. <lengthy description saying the same thing 3 times in different ways>”

The diff: changes to one (1) file completely unrelated to the feature, no tests, and the only change is to *undo the prettier formatting of that one file*.

Are you running the latest linter? I’m surprised you’re getting rules of hooks violations if your LLM can see the linter errors. What’s your setup like?

RC uses a control flow graph and SSA form, and does static analysis incl type inference, constant folding, dead code elimination, escape analysis, etc. I’m not aware of any other tool that does this degree of low-level analysis+optimization that isn’t referred to as a compiler.

Was the build already using Babel? I’m wondering if the hit was simply from adding the plugin or whether it was bc it triggered switching from a faster build toolchain.

React Compiler – React The library for web and native user interfaces

Can you give this a try? react.dev/learn/react-...

The compiler now powers eslint-plugin-react-hooks. The specific validation (for setState in the top level of use effect) isn’t enabled by default yet, but we’ll turn it on before stable.

React Compiler in fact does already have a lint rule against this.

People can intentionally write bad code in any framework. You can do the exact same anti-pattern in any React competitor.

It certainly can be done, but there’s no precedent for this in the ecosystem. ESLint, TypeScript, Flow, etc will report errors but never prevent you from running your code. The only thing that can really get in the way of that is a syntax error, which is a low bar.

Gotcha. That all makes sense with the extra context!

Basically, whether you ship compiled code or not is purely an implementation detail to your users. You could have done all that memoization manually! As long as you’ve tested and are confident, why not ship as the default?

I don’t quite get why you’d do that, but it doesn’t seem harmful so 🤷‍♂️

Yeah, bundling in the compiler runtime is the right call for now. It’s small and as you noted in replies, it’s designed as a polyfill.

I overestimated the number of people who’d be working today lol. Will follow up early next week. But in general, I would recommend waiting to ship a precompiled stable release until we have a stable runtime version to depend on.

We are all off today, but I’ll sync w the team and report back tomorrow

Anything we can do to support? I somehow missed that WG post, not sure if those questions are still relevant

We try to attend a bunch of them, I think schedules just didn’t work out for this one 🤷‍♂️

1) us too!
2) over a year ago we started internally using a TC39-inspired staging system for features. We publicly share what’s in dev (labs posts), canary, and stable.
3) we agree! We’ve tried multiple approaches to working groups w mixed success and we’ll keep iterating

Sorry to hear it didn’t work out for you! What are the main libraries you’re using for state management and data loading? Maybe a library was incompatible

This is a good question. We have been in the fence about whether and how to surface these cases, because it’s not necessarily a problem. You already have memoization. Im curious for what would you’d find helpful here

We might be missing a declaration for sort too. I know we have map/filter and a few others. If you want to contribute look for those methods in ObjectShape.ts and add the missing ones! :-)

Yes but not for that example. There, it’s bailing out bc we are missing a declaration for `Array.proto.toSorted` so we don’t realize it returns an array, and therefore don’t know that the later .map call isn’t mutating

@gsathya.bsky.social this formalizes the previous Store/Capture semantic we came up w, and allows us to infer precise effects across function expression boundaries

I think there’s probably an element where if you’re sharing historical context you want multiple perspectives, and a single person’s written account of a complex thing just isn’t enough. Good history books and documentaries account for this.

Really appreciate the kind words. Re the first half: I have worked on 3-4 systems that at runtime do incremental computation (of which signals are a variant), and use advanced compilation to provide a “plain-value” API w no explicit reactive values. Compilation is a super power, full stop.

WIP writeup of the core inference rules that power React Compiler (coinciding w rewriting the guts of this algorithm to be more consistent, precise and powerful, especially for function expressions)

github.com/facebook/rea...

For a year+ we’ve been following a staging system inspired by TC39 for React development. It’s a great model. We don’t publish precise details on early stages, but focus on communicating what’s in dev (labs posts), canary, and stable.

If you call a hook on first render, then don’t call it in the next render, then call it again in 3rd render, does its state reset or not? Both answers make sense and whichever default you pick will confuse some users.

bsky.app/profile/en-j...

We may explore conditional hooks at some point but not imminently. We weren’t blocked on the compiler to support them, it’s a question of design and footguns.

Build performance is definitely something we’re watching out for, and the most practical path is to statically compile a modified version of the current code with Static Hermes. Minus the very thin Babel frontend, since the core logic is decoupled from Babel.

Vercel folks already contributed an integration that uses an embedded JS engine to run the compiler within SWC. Definitely has perf overhead though.