[pull] main from facebook:main #195
Merged
Conversation
This file contains hidden or 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}
…#33983) The `useOpenResource` hook is now used to open links. Currently, the `<>` icon for the component stacks and the link in the bottom of the components stack. But it'll also be used for many new links like stacks. If this new option is configured, and this is a local file then this is opened directly in the external editor. Otherwise it fallbacks to open in the Sources tab or whatever the standalone or inline is configured to use. <img width="453" height="252" alt="Screenshot 2025-07-24 at 4 09 09 PM" src="https://github.com/user-attachments/assets/04cae170-dd30-4485-a9ee-e8fe1612978e" /> I prominently surface this option in the Source pane to make it discoverable. <img width="588" height="144" alt="Screenshot 2025-07-24 at 4 03 48 PM" src="https://github.com/user-attachments/assets/0f3a7da9-2fae-4b5b-90ec-769c5a9c5361" /> When this is configured, the "Open in Editor" is hidden since that's just the default. I plan on deprecating this button to avoid having the two buttons going forward. Notably there's one exception where this doesn't work. When you click an Action or Event listener it takes you to the Sources tab and you have to open in editor from there. That's because we use the `inspect()` mechanism instead of extracting the source ___location. That's because we can't do the "throw trick" since these can have side-effects. The Chrome debugger protocol would solve this but it pops up an annoying dialog. We could maybe only attach the debugger only for that case. Especially if the dialog disappears before you focus on the browser again.
When the browser theme changes, we don't immediately rerender the UI so we don't pick up the new theme if the React devtools are set to auto. This picks up the change immediately.
We should jump to the right column. Unfortunately, the way presets are set up now you have to switch off and switch to the preset for this to take effect.
…l editor (#33985) Stacked on #33983. Allow React to be configured as the default handler of all links in Chrome DevTools. To do this you need to configure the Chrome DevTools setting for "Link Handling:" to be set to "React Developer Tools". By default this doesn't do anything but if you then check the box added in #33983 it starts open local files directly in the external editor. This needs docs to show how to enable that option. (As far as I can tell this broke in Chrome Canary 🙄 but hopefully fixed before stable.)
…r presets (and make VSCode default) (#33995) Stacked on #33983. Previously, the source of truth is the url stored in local storage but that means if we change the presets then they don't take effect (e.g. #33994). This PR uses the hardcoded value instead when a preset is selected. This also has the benefit that if you switch between custom and vs code in the selector, then the custom url is preserved instead of getting reset when you checkout other options. Currently the default is custom with empty string, which means that there's no code editor configured at all by default. It doesn't make a lot of sense that we have it not working by default when so many people use VS Code. So this also makes VS Code the default if there's no EDITOR_URL env specified.
#33984) Fixes two related cases of mutation of potentially frozen values. The first is method calls on frozen values. Previously, we modeled unknown function calls as potentially aliasing their receiver+args into the return value. If the receiver or argument were known to be frozen, then we would downgrade the `Alias` effect into an `ImmutableCapture`. However, within a function expression it's possible to call a function using a frozen value as an argument (that gets `Alias`-ed into the return) but where we don't have the context locally to know that the value is frozen. This results in cases like this: ```js const frozen = useContext(...); useEffect(() => { frozen.method().property = true; ^^^^^^^^^^^^^^^^^^^^^^^^ cannot mutate frozen value }, [...]); ``` Within the function we would infer: ``` t0 = MethodCall ... Create t0 = mutable Alias t0 <- frozen t1 = PropertyStore ... Mutate t0 ``` And then transitively infer the function expression as having a `Mutate 'frozen'` effect, which when evaluated against the outer context (`frozen` is frozen) is an error. The fix is to model unknown function calls as _maybe_ aliasing their receiver/args in the return, and then considering mutations of a maybe-aliased value to only be a conditional mutation of the source: ``` t0 = MethodCall ... Create t0 = mutable MaybeAlias t0 <- frozen // maybe alias now t1 = PropertyStore ... Mutate t0 ``` Then, the `Mutate t0` turns into a `MutateConditional 'frozen'`, which just gets ignored when we process the outer context. The second, related fix is for known mutation of phis that may be a frozen value. The previous inference model correctly recorded these as errors, the new model does not. We now correctly report a validation error for this case in the new model. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33984). * #33993 * #33991 * __->__ #33984
--- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33991). * #33993 * __->__ #33991 * #33984
…33993) The test case here previously reported a "Cannot modify local variables after render completes" error (from ValidateNoFreezingKnownMutableFunctions). This happens because one of the functions passed to a hook clearly mutates a ref — except that we try to ignore mutations of refs! The problem in this case is that the `const ref = ...` was getting converted to a context variable since the ref is accessed in a function before its declaration. We don't infer types for context variables at all, and our ref handling is based on types, so we failed to ignore this ref mutation. The fix is to recognize that `StoreLocal const ...` is a special case: the variable may be referenced in code before the declaration, but at runtime it's either a TDZ error or the variable will have the type from the declaration. So we can safely infer a type. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33993). * __->__ #33993 * #33991 * #33984
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.3)
Can you help keep this open source service alive? 💖 Please sponsor : )