We’re pretty close to having an initial Rust port of React Compiler. My approach was to iterate on the plan document (write it manually, have the agent expand, edit, repeat). Then try to run it, see what goes wrong, revert back to the plan, tweak the plan, repeat.
IIRC we didn’t do that because we would like to change it to be an installer to select any of the well known frameworks instead
Does this implement the performance tracks for server components and server requests yet?
100% agree
useActionState is a new hook for forms, async reducers, and more. It now has great new documentation: react.dev/reference/re...
Thank you to @ricky.fm for writing.
Thank you to @aurorascharff.no, @danabra.mov, @samselikoff.com, @stephanjnoel.bsky.social, @brenelz.com, and @yadiel.dev for reviewing.
Oh I see what you mean. Yeah I don’t know how you would do that with this hook though.
If you’re posting to a /toggle endpoint it’s still not safe. Not sure there’s general guidance here. That’s why for most cases I would either just let them queue (using optimistic to update the UI), or disable the button while in flight
That already works, this is the trace I built the docs from
trace.cafe/t/BseVMSJlNx
We did, check out: react.dev/reference/de...
The thing I'm adding is being able to show what the DevTools Profiler will show you when you run it, embedded in the docs themselves.
For tracking where updates came from, you can click the "update" in the tracks to see were the setState came from.
Here's an example: react.dev/reference/de...
We show the component tree in the Components track. We'd like to make it easy to click to go to the Components tab for React DevTools, but that requires the browser to add link support.
Does this diagram help? It uses the React Performance Tracks to explain what React is doing, and what you'll see when you use the tracks:
github.com/reactjs/reac...
Adding more information to React error pages
github.com/reactjs/reac...
You can use Fragment refs for observers, but otherwise it's not clear why you can't use an effect for this?
useEffectEvent makes handling events in Effects much easier and saves unnecessary unmounting and remounting of listeners. It now has awesome new docs: react.dev/reference/re...
Thank you to @ricky.fm the updates, and @danabra.mov and @stephanjnoel.bsky.social for reviewing
adding event handlers is subscribing to an external system (the DOM) so it fits for events.
Take me down to the Parallax city where the far moves slow and the near moves quickly
Why do you need to attach the listener in a ref callback? We flush effects sync in updates for user events exactly for this use case
Yes
There are two blockers to autodeps. 1) people really hate the idea of not seeing the array (but that’s fine, you could still choose to write it) and 2) if you think about useEffectEvent primarily as “untracked” then you need to see the deps. But if you think of it as separating events, you don’t
Yeah I love that. And that works with my other concern: how does this make sense with auto deps where you don’t write/see the dependency array.
It’s a caveat listed below this
My thought process is “i need to connect to a socket and subscribe to a connect event. I don’t want to resubscribe for that event, so let me move this to an effect event”
The problem is thinking from the components perspective (how props flow in) not the effects perspective (what values resubscribe).
The thought process should be the same with or without the dependency array.
It doesn’t do any tracking internally it just mutates a ref with the last rendered function to update the closure.
@ricky.fm Thank you for updating react.dev/reference/re... page.
Also thanks to @danabra.mov, @aurorascharff.no @stephanjnoel.bsky.social, @brenelz.com for adding feedback
Btw the preview link works
What's the use case?
Maybe it's
"This lets you call this function from a Effect as an "event". Since it's an event, the Effect does not need to include it as a dependency. Please read Dan's learn docs about this, they're very good."
