[pull] main from facebook:main #42
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Will run a quick experiment for this.
Stacked on #31729 <img width="1436" alt="Screenshot 2024-12-11 at 3 36 41 PM" src="https://github.com/user-attachments/assets/0a201913-0076-4bbf-be18-8f1df6c58313" /> The Server Components visualization is currently a tree flame graph where parent spans the child. This makes it equivalent to the Client Components visualization. However, since Server Components can be async and therefore parallel, we need to do something when two children are executed in parallel. This PR bumps parallel children into a separate track and then within that track if that child has more children it can grow within that track. I currently just cut off more than 10 parallel tracks. Synchronous Server Components are still in sequence but it's unlikely because even a simple microtasky Async Component is still parallel. <img width="959" alt="Screenshot 2024-12-11 at 4 31 17 PM" src="https://github.com/user-attachments/assets/5ad6a7f8-7fa0-46dc-af51-78caf9849176" /> I think this is probably not a very useful visualization for Server Components but we can try it out. I'm also going to try a different visualization where parent-child relationship is horizontal and parallel vertical instead, but it might not be possible to make that line up in this tool. It makes it a little harder to see how much different components (including their children) impact the overall tree. If that's the only visualization it's also confusing why it's different dimensions than the Client Component version.
We introduced the `unstable_useContextWithBailout` API to run compiler based experiments. This API was designed to be an experiment proxy for alternative approaches which would be heavier to implement. The experiment turned out to be inconclusive. Since most of our performance critical usage is already optimized, we weren't able to find a clear win with this approach. Since we don't have further plans for this API, let's clean it up.
…/Components Tracks (#31736) Stacked on #31735. This ensures that Server Components Track comes first. Since it's typically rendered first on the server for initial load and then flows into scheduler and client components work. Also puts it closer to the Network and further away from "Main" JS. <img width="769" alt="Screenshot 2024-12-11 at 5 31 41 PM" src="https://github.com/user-attachments/assets/7198db0f-075e-4a78-8ea4-3bfbf06727cb" /> Same trick as in #31615.
Stacked on #31736. <img width="1223" alt="Screenshot 2024-12-11 at 8 21 12 PM" src="https://github.com/user-attachments/assets/a7cbc04b-c831-476b-aa2f-baddec9461c9" /> This emits a placeholder when we're deduping a component. This starts when the parent's self time ends, where we would've started rendering this component if it wasn't already started. The end time is when the actual render ends since the parent is also blocked by it.
Stacked on #31737. <img width="987" alt="Screenshot 2024-12-11 at 8 41 15 PM" src="https://github.com/user-attachments/assets/438379a9-0138-4d02-a53a-419402839558" /> When mixing environments (like "use cache" or third party RSC) it's useful to color and badge those components differently to differentiate. I'm not putting them in separate tracks because when they do actually execute, like cache misses or third party RSCs, they behave like they're part of the same tree.
Compiler playground now runs the entire program through `babel-plugin-react-compiler` instead of a custom pipeline which previously duplicated function inference logic from `Program.ts`. In addition, the playground output reflects the tranformed file (instead of a "virtual file" of manually concatenated functions). This helps with the following: - Reduce potential discrepencies between playground and babel plugin behavior. See attached fixture output for an example where we previously diverged. - Let playground users see compiler-inserted imports (e.g. `_c` or `useFire`) This also helps us repurpose playground into a more general tool for compiler-users instead of just for compiler engineers. - imports and other functions are preserved. We differentiate between imports and globals in many cases (e.g. `inferEffectDeps`), so it may be misleading to omit imports in printed output - playground now shows other program-changing behavior like position of outlined functions and hoisted declarations - emitted compiled functions do not need synthetic names --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31774). * #31809 * __->__ #31774
Clean up duplicate checks for when to skip processing values as dependencies / hoistable temporaries. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31581). * #31583 * #31582 * __->__ #31581
Avoid mutable logging enabled state and writing to `process.stdout` within our babel transform.
Config flag for `fire` -- --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31794). * #31811 * #31798 * #31797 * #31796 * #31795 * __->__ #31794
Makes `fire` a known export for type-based analysis -- --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31795). * #31811 * #31798 * #31797 * #31796 * __->__ #31795 * #31794
We previously didn't track context variables in the hoistable values
sidemap of `propagateScopeDependencies`. This was overly conservative as
we *do* track the mutable range of context variables, and it is safe to
hoist accesses to context variables after their last direct / aliased
maybe-assignment.
```js
function Component({value}) {
// start of mutable range for `x`
let x = DEFAULT;
const setX = () => x = value;
const aliasedSet = maybeAlias(setX);
maybeCall(aliasedSet);
// end of mutable range for `x`
// here, we should be able to take x (and property reads
// off of x) as dependencies
return <Jsx value={x} />
}
```
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31582).
* #31583
* __->__ #31582
Add shape / type for global Object.keys. This is useful because - it has an Effect.Read (not an Effect.Capture) as it cannot alias its argument. - Object.keys return an array --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31583). * __->__ #31583 * #31582
It's on everywhere else, let's turn this on so we can remove it. Probably should have been turned on in the test renderer for 19.
TODO: test this PR to see what internal tests fail
…1761) This flag controls the strict mode double invoke render/lifecycles/etc behavior in Strict Mode. The only place this flag is off is the test renderers, which it should be on for. If we can land this, we can follow up to remove the flag.
These flags are hardcoded now, we can make them static.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )