Question:
Do you want to request a feature or report a bug? Bug What is the current behavior? is never set to true when calling within , but it does work properly when within a . Here's the correct behavior (accomplished via ): ! Here's the incorrect behavior (via ): ! Note the difference is that the opacity never changes to 0.4 (which is determined based on the state). What is the expected behavior? I expect them to both behave the same (at least as far as the user can observe). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react react-dom
I guess startTransition is never intended to be used in effects. I didn't expect it even works. Looking at the doc again, Hmm, it doesn't clearly say so.
Ok but the use cases is interesting.
Do you think this is the same as
Yes, I believe that's the same issue.
Hello, I think I have a similar issue when using with . When returns a new value I would like to create a new resource. I tried to use for this, but I don't even have an idea where to put ...
you can see the isPending is if the is bigger than 5100 when calling in .
I'm seeing the same behavior as - setting to a value of 5200 or higher causes to fire reliably in the original CodeSandbox:
That is a bug we need to fix regardless.
Fixed by . Updated Sandbox:

import type {SuspenseConfig} from './ReactFiberSuspenseConfig'; import type {ReactPriorityLevel} from './SchedulerWithReactIntegration'; <del> import * as Scheduler from 'scheduler'; </del> import ReactSharedInternals from 'shared/ReactSharedInternals'; import {NoWork} from './ReactFiberExpirationTime';

import is from 'shared/objectIs'; import {markWorkInProgressReceivedUpdate} from './ReactFiberBeginWork'; import {requestCurrentSuspenseConfig} from './ReactFiberSuspenseConfig'; <del> import {getCurrentPriorityLevel} from './SchedulerWithReactIntegration'; </del> <ins> import { UserBlockingPriority, NormalPriority, runWithPriority, getCurrentPriorityLevel, } from './SchedulerWithReactIntegration'; </ins> const {ReactCurrentDispatcher, ReactCurrentBatchConfig} = ReactSharedInternals;

const [prevValue, setValue] = mountState(value); mountEffect( () => { <del> Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); </del> <ins> const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } </ins> }, [value, config], );

const [prevValue, setValue] = updateState(value); updateEffect( () => { <del> Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); </del> <ins> const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } </ins> }, [value, config], ); return prevValue; } <ins> function startTransition(setPending, config, callback) { const priorityLevel = getCurrentPriorityLevel(); runWithPriority( priorityLevel < UserBlockingPriority ? UserBlockingPriority : priorityLevel, () => { setPending(true); }, ); runWithPriority( priorityLevel > NormalPriority ? NormalPriority : priorityLevel, () => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }, ); } </ins> function mountTransition( config: SuspenseConfig | void | null, ): [(() => void) => void, boolean] { const [isPending, setPending] = mountState(false); <del> const startTransition = mountCallback( callback => { setPending(true); Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); }, [config, isPending], ); return [startTransition, isPending]; </del> <ins> const start = mountCallback(startTransition.bind(null, setPending, config), [ setPending, config, ]); return [start, isPending]; </ins> } function updateTransition( config: SuspenseConfig | void | null, ): [(() => void) => void, boolean] { const [isPending, setPending] = updateState(false); <del> const startTransition = updateCallback( callback => { setPending(true); Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); }, [config, isPending], ); return [startTransition, isPending]; </del> <ins> const start = updateCallback(startTransition.bind(null, setPending, config), [ setPending, config, ]); return [start, isPending]; </ins> } function dispatchAction<S, A>(

<ins> /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @emails react-core * @jest-environment node */ 'use strict'; let ReactFeatureFlags; let React; let ReactNoop; let Scheduler; let Suspense; let useState; let useTransition; let act; describe('ReactHooksWithNoopRenderer', () => { beforeEach(() => { jest.resetModules(); ReactFeatureFlags = require('shared/ReactFeatureFlags'); ReactFeatureFlags.debugRenderPhaseSideEffectsForStrictMode = false; ReactFeatureFlags.enableSchedulerTracing = true; ReactFeatureFlags.flushSuspenseFallbacksInTests = false; React = require('react'); ReactNoop = require('react-noop-renderer'); Scheduler = require('scheduler'); useState = React.useState; useTransition = React.useTransition; Suspense = React.Suspense; act = ReactNoop.act; }); function Text(props) { Scheduler.unstable_yieldValue(props.text); return props.text; } function createAsyncText(text) { let resolved = false; let Component = function() { if (!resolved) { Scheduler.unstable_yieldValue('Suspend! [' + text + ']'); throw promise; } return <Text text={text} />; }; let promise = new Promise(resolve => { Component.resolve = function() { resolved = true; return resolve(); }; }); return Component; } it('isPending works even if called from outside an input event', async () => { const Async = createAsyncText('Async'); let start; function App() { const [show, setShow] = useState(false); const [startTransition, isPending] = useTransition(); start = () => startTransition(() => setShow(true)); return ( <Suspense fallback={<Text text="Loading..." />}> {isPending ? <Text text="Pending..." /> : null} {show ? <Async /> : <Text text="(empty)" />} </Suspense> ); } const root = ReactNoop.createRoot(); await act(async () => { root.render(<App />); }); expect(Scheduler).toHaveYielded(['(empty)']); expect(root).toMatchRenderedOutput('(empty)'); await act(async () => { start(); expect(Scheduler).toFlushAndYield([ 'Pending...', '(empty)', 'Suspend! [Async]', 'Loading...', ]); expect(root).toMatchRenderedOutput('Pending...(empty)'); await Async.resolve(); }); expect(Scheduler).toHaveYielded(['Async']); expect(root).toMatchRenderedOutput('Async'); }); }); </ins>


Question:
Steps to reproduce: 1) Disable all add-ons in Firefox 2) Open an URL that points to a XML file 3) AS EXPECTED: A pretty-printed XML is shown 4) Enable the React DevTools Add-on 5) Open the XML file again 6) FAIL: Only the content inside the XML tags are shown Using Firefox Developer Edition 72.0b6 on macOS 10.15.2
I am able to reproduce the behavior described using Firefox Developer Edition (72.0b1) but regular Firefox (71.0) does not exhibit the buggy behavior. I don't believe this is something that the React DevTools add-on should be able to cause, since syntax highlighting is a built-in browser feature. There is no error in the console (or the add-on if I inspect it). Just enabling the extension is enough to immediately "break" pretty-print for XML files, e.g. I believe that this may be a Firefox Developer Edition bug. It's probably not something that an extension should be able to cause. I'll open a bug on their end: cc
Thanks! I see the same with and the LastPass add-on
It's unclear what Firefox is going to do on their end about this, but it seems like we can make this better by checking in the content script if is "text/xml" before injecting any tags.
This will be fixed in the next release.
FYI this issue should be fixed in v4.4 (released today)

injectCode(rendererCode); } <del> // Inject a `__REACT_DEVTOOLS_GLOBAL_HOOK__` global so that React can detect that the // devtools are installed (and skip its suggestion to install the devtools). injectCode( ';(' + installHook.toString() + '(window))' + saveNativeValues + detectReact, ); </del> <ins> // Inject a __REACT_DEVTOOLS_GLOBAL_HOOK__ global for React to interact with. // Only do this for HTML documents though, to avoid e.g. breaking syntax highlighting for XML docs. if (document.contentType === 'text/html') { injectCode( ';(' + installHook.toString() + '(window))' + saveNativeValues + detectReact, ); } </ins>


Question:
! There's seems to be circumstances where unmounted DOM/Fibers are kept alive by React DevTools. They're kept alive in : It seems like a WeakSet would be appropriate and would remove the leak. Otherwise we'd need to understand why recordUnmount isn't called. CC
I'm not necessarily convinced that the above screenshot is showing what this issue suggests. I believe it's possible that this indicates that component rendered where it previously rendered a DOM element, and the "alternate" Fiber still has a reference to the (now unmounted) DOM element. In this case both DevTools and React itself would have references to both Fibers as well as the unmounted DOM element. We do clear pointers for both "current" and "alternate" in but this does not include the property: The retain behavior I describe above can be verified with the following example app code: I'm not sure I would call this a "leak", since the retained DOM elements would go away once the leaf Fiber itself went away, but it could at least exhibit the behavior your Memory profile shows in the picture above. If one was to argue this was a leak, then I believe it would be considered a React leak rather than a DevTools leak. Edit I think we also leak Fibers in this way, since the may have a reference to its previous children - which themselves have references to their Fibers via the "__reactInternalInstance" field.
Quick update about this issue and PR The thing that caused the above temporarily "leak" is the alternate pointer- which will be cleared during the next render. That being said, the reason the temporary "leak" retains so much (the whole subtree) is because we weren't nulling out the field. PR changes this behavior so that we now will null that field. This should make our memory snapshot comparisons less noisy in the future. In other words, hopefully this will show that DevTools isn't actually leaking DOM nodes (and Fibers) but if it is at least we should be able to identify them less ambiguously now.
Looks like there is a memory leak in DevTools, was noticed in Created small demo, it can be observer while scrolling a list, memory increase because of detached fiber and dom elements It happens also in production build, noticed that elements aren't removed from after they are unmounted, something fishy there
Thanks for sharing a repro, I'll take a look.
It does look like DevTools isn't recording unmounts for list-item Fibers in this repro, which causes it to retain them after they've been unmounted. This might have been a bad lead here. I think the reason I'm initially not seeing calls to commit unmount are because grows a pool of items initially. Still digging. It's definitely the list items that are leaking though. Just not sure why yet. Update I'm not convinced this is the entire problem, but it does seem like DevTools isn't properly cleaning out all of the alternate entries in the Map. I think this is because the is being cleared out synchronously by React when a Fiber gets unmounted (as part of our memory cleanup flag) but DevTools is asynchronously processing the untracking in order to support fast Refresh: The previous update is the problem. I think I have a fix. Will be pushing shortly.
Also as side note, i would expect to see similar behaviour in react-window, as in windowing nature there is lot of mounting/unmounting, only difference to react-virtual is, that it's hook based and react-window on classes.
This fix will go out with the next DevTools release.
Thanks

untrackFibersSet.add(fiber); <ins> // React may detach alternate pointers during unmount; // Since our untracking code is async, we should explicily track the pending alternate here as well. const alternate = fiber.alternate; if (alternate !== null) { untrackFibersSet.add(alternate); } </ins> if (untrackFibersTimeoutID === null) { untrackFibersTimeoutID = setTimeout(untrackFibers, 1000); }


Question:
React version: 16.8.0 an app that toggles between rendering a text input and a date input. the of each to some arbitrary input, valid for either one toggling occurs that the value of the date input is not preserved upon toggle The date input's value is not preserved The date input's value should be preserved We discovered a simple workaround--add a unique property to each input, and the value will be respected.
It seems to be the default correct behaviour. You can read more about how works here. The reason it seems to work by adding the key prop is because the component gets re-rendered from scratch and therefore the "works". I think what you want to achieve is pretty date display when not in edit mode. Maybe something like this. Demo Prototype code
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

var args = [ "bin/jsx", "--cache-dir", ".module-cache", <ins> "--relativize", </ins> config.sourceDir, config.outputDir ];

}, "dependencies": { "base62": "~0.1.1", <del> "commoner": "~0.6.8", </del> <ins> "commoner": "~0.7.0", </ins> "esprima": "git://github.com/facebook/esprima#fb-harmony", <del> "recast": "~0.3.3", </del> <ins> "recast": "~0.4.5", </ins> "source-map": "~0.1.22" }, "devDependencies": {


Question:
I don't see the selection at all. My version is 4.5.0. I think this regressed. <img width="266" alt="Screenshot 2020-03-11 at 23 40 37" src="https://user-"
This is interesting. The extension seems to have a shorter toolbar height than I would expect, which is clipping the current index. Here's what the test harness/shell looks like: <img width="437" alt="Screen Shot 2020-03-11 at 6 11 50 PM" src="https://user-"
Looks like something is going wrong with the relative height of the list items in the extension. Works fine in Chrome but it's overflowing in the extension.
Ah, it looks like the style isn't cascading correctly in the extension.
I think this probably regressed with , because the extension uses portals to mount (so they don't get mounted underneath of the class).
Yay! Fixed. <img width="369" alt="Screen Shot 2020-03-11 at 6 35 52 PM" src="https://user-"

font-family: var(--font-family-sans); } <ins> .Components, .Components * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); } </ins> .TreeWrapper { flex: 0 0 var(--horizontal-resize-percentage); overflow: auto;

.DevTools, .DevTools * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); }

color: var(--color-text); } <ins> .Profiler, .Profiler * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); } </ins> .LeftColumn { display: flex; flex-direction: column;


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: eslint-plugin-react-hooks to Releases on GitHub there about eslint-plugin-react-hooks to look for a CHANGELOG for eslint-plugin-react-hooks CHANGELOG <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Not code related. <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --No change logs. Change logs on the Releases page for eslint-plugin-react-hooks or a separate CHANGELOG. Especially for major version changes so developers are aware of breaking changes that need to be fixed/prioritised. Thank you.
Please feel free to help out filling that in. Thanks!
Thanks. I tried searching for an existing issue but couldn't find one so I thought I'd mention it. I've gone through the commit history (standard process without release notes) but without existing knowledge of the codebase, it's a bit hard to understand what changes affect the user and how. So I'll leave someone more in-the-know to write it. :bowing_man:

<ins> ## 4.0.0 * **New Violations:** Consider `PascalCase.useFoo()` calls as Hooks. ([@cyan33](https://github.com/cyan33) in [#18722](https://github.com/facebook/react/pull/18722)) * **New Violations:** Check callback body when it's not written inline. ([@gaearon](https://github.com/gaearon) in [#18435](https://github.com/facebook/react/pull/18435)) * Add a way to enable the dangerous autofix. ([@gaearon](https://github.com/gaearon) in [#18437](https://github.com/facebook/react/pull/18437)) * Offer a more sensible suggestion when encountering an assignment. ([@Zzzen](https://github.com/Zzzen) in [#16784](https://github.com/facebook/react/pull/16784)) * Consider TypeScript casts of `useRef` as constant. ([@sophiebits](https://github.com/sophiebits) in [#18496](https://github.com/facebook/react/pull/18496)) * Add documentation. ([@ghmcadams](https://github.com/ghmcadams) in [#16607](https://github.com/facebook/react/pull/16607)) ## 3.0.0 * **New Violations:** Forbid calling Hooks from classes. ([@ianobermiller](https://github.com/ianobermiller) in [#18341](https://github.com/facebook/react/pull/18341)) * Add a recommended config. ([@SimenB](https://github.com/SimenB) in [#14762](https://github.com/facebook/react/pull/14762)) ## 2.5.0 * Fix a misleading error message in loops. ([@M-Izadmehr](https://github.com/M-Izadmehr) in [#16853](https://github.com/facebook/react/pull/16853)) ## 2.4.0 * **New Violations:** Run checks for functions passed to `forwardRef`. ([@dprgarner](https://github.com/dprgarner) in [#17255](https://github.com/facebook/react/pull/17255)) * **New Violations:** Check for ref usage in any Hook containing the word `Effect`. ([@gaearon](https://github.com/gaearon) in [#17663](https://github.com/facebook/react/pull/17663)) * Disable dangerous autofix and use ESLint Suggestions API instead. ([@wdoug](https://github.com/wdoug) in [#17385](https://github.com/facebook/react/pull/17385)) ## 2.0.0 * **New Violations:** Forbid calling Hooks at the top level. ([@gaearon](https://github.com/gaearon) in [#16455](https://github.com/facebook/react/pull/16455)) * Fix a crash when referencing arguments in arrow functions. ([@hristo-kanchev](https://github.com/hristo-kanchev) in [#16356](https://github.com/facebook/react/pull/16356)) ## 1.x The 1.x releases aren’t noted in this changelog, but you can find them in the [commit history](https://github.com/facebook/react/commits/master/packages/eslint-plugin-react-hooks). </ins>


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React Dev Tools version: 4.6.0 I'm not sure there is a problem with within package, or it's just my misunderstand how it works, but script create production build. Command above runs a each script (per browser) in which is set to . run in creates minified version of files. where has set to . Each step in should be replaced from to
Send a PR? This does look odd.
Sure, I'll take a look at it tomorrow, it's looks odd and incorrectly but need to check there isn't any trap with that

"private": true, "scripts": { "build": "cross-env NODE_ENV=production yarn run build:chrome && yarn run build:firefox && yarn run build:edge", <del> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome && yarn run build:firefox && yarn run build:edge", </del> <ins> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome:dev && yarn run build:firefox:dev && yarn run build:edge:dev", </ins> "build:chrome": "cross-env NODE_ENV=production node ./chrome/build", "build:chrome:crx": "cross-env NODE_ENV=production node ./chrome/build --crx", "build:chrome:dev": "cross-env NODE_ENV=development node ./chrome/build",


Question:
Compare two screenshots closely. The space after "from" disappears when the next word is selected. <img width="574" alt="Screenshot 2020-04-07 at 13 26 40" src="https://user-"<img width="776" alt="Screenshot 2020-04-07 at 13 26 35" src="https://user-"
Oops. Yeah this looks like a CSS bug. Each row in the tree is . This means that gets smushed together in a way we don't want. Need to think about this for a minute.

.Wrapper { padding: 0 0.25rem; <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> height: var(--line-height-data); line-height: var(--line-height-data); display: inline-flex;


Question:
did profiling on a list, that gets updated on each pagination api call. the profiling was done, I moved around in the Profiler to view the Flamegraph to second capture, the Profiler crashed. DevTools version: 4.6.0-
What does this mean? Can you repro this bug? And if so, could you share steps for repro with us?
Sorry for not providing enough details, but even I don't have enough details. This error just popped up when I was profiling my app in React Devtools. I was profiling a normal () list, and it broke when I clicked next button on DevTools, to see the recorded profile. <img width="1149" alt="Screenshot 2020-05-08 at 11 12 50 AM" src="https://user-"About having a repro, I couldn't replicate it myself after that one occurrence, again. Anyways, my assumption is (it could be wrong), one of the list item in the flame graph is getting duplicated somehow, either due to the app it was profiling or due to something else.
Okay. Thanks for clarifying.
If no-one is working on this, I would like to assign myself to investigate and fix the issue (since multiple people have referenced it). Also, If you assign me, Can you please also help me with where to look?
If you'd like to dig into this, we'd be happy to have the help. I don't really have the bandwidth to guide you on it though. Some places you'd want to look at for starters:    And for a general overview of how DevTools works, you can check out this:
This error remains the highest reported DevTools bug but we still don't have a repro case so that I can fix it. Do you remember how to repro the error you saw above? Can you share the steps with me if so? It would be very helpful! Thank you
Hi Will try to replicate it again... It's been a long time since I used the Profiler, so I don't remember much.
Okay, understood! Either way, thanks for checking.
I've got a repro for this over on : When I run this project, I see an error in DevTools: This is very promising! Looks like there's a problem with Suspense and LegacyHidden.
I think the case I'm seeing is this: initial render, a Suspense component is mounted. has an Offscreen child, b'c of how Suspense is implemented internally, but DevTools hides this implementation detail to avoid confusion. (What this actually means is that the DevTools backend never even tells the frontend that the Offscreen component exists.) login, stuff is updated and for some reason, the backend thinks it needs to unmount the Offscreen component (even though the frontend never knew about it). This causes an error to be thrown. Unfortunately this thrown error is not surfaced in the UI so things go on until later, when it causes a downstream error in the Profiler. First step is making that first error visible (done via ). Second step is to figure out why it's happening. Interestingly, if I trim down the repro a to the minimal repro case, then copy that into the React DevTools test harness (with a bleeding edge build of react and react-dom) the bug no longer happens. Edit 1: If I copy it instead into a project created by – with the same major versions of react and react-dom, I can repro the bug. So that's good. Seems like something may have changed on the React side between 17.0.2 and HEAD? Edit 2: One (possibly) significant difference between the two versions is that 17 uses the component beneath but HEAD uses the newer component. I can also repro the same error in the DevTools test shell by swapping with so...
Oooh looks like this may have just been an oversight in our filtering logic. (We filter but not components. Eventually we'll not want to filter but for now, that seems an easy fix.
This bug fix has been released as 4.13.1

onHookOperations = (operations: Array<number>) => { if (__DEBUG__) { <del> debug('onHookOperations', operations); </del> <ins> debug( 'onHookOperations', `(${operations.length}) [${operations.join(', ')}]`, ); </ins> } // TODO:

HostText, IncompleteClassComponent, IndeterminateComponent, <ins> LegacyHiddenComponent, </ins> MemoComponent, OffscreenComponent, SimpleMemoComponent,

case HostPortal: case HostText: case Fragment: <ins> case LegacyHiddenComponent: </ins> case OffscreenComponent: return true; case HostRoot:


Question:
eslint yesterday. gets a peerDependency warning: Ensure compatibility with the newly released major and add to .
Oh I just realized is coming from another repo: Will open an issue there as well and edit this one.


Question:
This doesn't actually run any DevTools tests. It runs the main React tests. Console output shows that it's choosing the wrong config: I wonder if this is also happening for other targets?
It's because of this: DevTools uses both and

function getCommandArgs() { // Add the correct Jest config. const args = ['./scripts/jest/jest.js', '--config']; <del> if (argv.build) { </del> <ins> if (argv.project === 'devtools') { args.push(devToolsConfig); } else if (argv.build) { </ins> args.push(buildConfig); } else if (argv.persistent) { args.push(persistentConfig); <del> } else if (argv.project === 'devtools') { args.push(devToolsConfig); </del> } else if (isWWWConfig()) { args.push(wwwConfig); } else if (isOSSConfig()) {


Question:
React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!

* ${license} */ <del> 'use strict'; </del> ${source}`; },


Question:
It looks like the property inspector inside React DevTools is not rendering repeating spaces properly. I imagine this can result in some fairly frustrating debugging sessions when doing something like string matching a component that takes a string as a property. multiple spaces in a row to that property (I would type the actual spaces, but it appears Github truncates the extra spaces even inside the code snippet!) that element inside React DevTools. The value of the prop is rendered as The value of the prop should be rendered as Below are some screenshots of the behavior I'm seeing in production. Here's how the property value is rendered in inspector when it is output directly to the HTML: ! And here is how that same value is rendered inside DevTools: !
Looks like is our culprit. According to we just need to change that from to . I will try to test that and put up a PR if it works.
You're correct. Interested in contributing a patch for it? (If not, I'm happy to– but since you've already done the work I thought I'd ask.)
I would be more than happy to! I'll aim to have something up by this evening.
PR is up and ready for review!

.Value { color: var(--color-attribute-value); <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> overflow: hidden; text-overflow: ellipsis; cursor: default;


}, );  if (__DEV__) { // Getting the name for the warning cause the loading to start early. expect(Scheduler).toHaveYielded(['Started loading']); expect(Scheduler).toFlushAndYield(['Loading...']); } else { expect(Scheduler).toFlushAndYield(['Started loading', 'Loading...']); }   expect(Scheduler).toFlushAndYield(['Started loading', 'Loading...']);  expect(root).not.toMatchRenderedOutput(
AB
); await Promise.resolve();

// TODO: an explicit expect for no warning? ReactDOM.render(JSXRuntime.jsx(Parent, {}), container); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); if (__DEV__) { JSXDEVRuntime.jsxDEV(Lazy, {}); } else { JSXRuntime.jsx(Lazy, {}); } expect(didCall).toBe(false); }); </ins> });

{withoutStack: true}, ); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); React.createElement(Lazy); expect(didCall).toBe(false); }); </ins> });

withoutStack: true, }); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); <Lazy />; expect(didCall).toBe(false); }); </ins> });

if (type === null || type === undefined || typeof type === 'string') { return; } <del> const name = getComponentName(type); </del> let propTypes; if (typeof type === 'function') { propTypes = type.propTypes;

return; } if (propTypes) { <ins> // Intentionally inside to avoid triggering lazy initializers: const name = getComponentName(type); </ins> checkPropTypes(propTypes, element.props, 'prop', name, element); } else if (type.PropTypes !== undefined && !propTypesMisspellWarningShown) { propTypesMisspellWarningShown = true; <ins> // Intentionally inside to avoid triggering lazy initializers: const name = getComponentName(type); </ins> console.error( 'Component %s declared `PropTypes` instead of `propTypes`. Did you misspell the property assignment?', name || 'Unknown',


Question:
Describe what you were doing when the bug occurred: back to go back through the frames following a profile session. I think I got to zero and then clicked it again and then it errored Please do not remove the text below this line DevTools version: 4.8.2- Call stack: at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) Component stack: at CommitRankedAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Please how do I replicate this? I don't seem to be able to replicate it.
sorry, I won't have time to create a mre. I was doing a recording on a site with a lot of components and a lot of frames in the recording. I ended up going to maybe frame 30 then clicking back rapidly to get back to 0 and I guess went to far or something. Feel free to close this, I thought that the logs might be enough and it was encouraging me to submit the issue.
Can I have a look ?
Maybe change this recursive function And use a loop going to correct the issue. If it is ok, i can work on it.
can you share how you were able to replicate the issue?
I think for there to be a stack overflow from calling itself, it would need to have profiling data with thousands (?) of commits. This function only recurses (at most) once per commit when processing data, and then, too, only if you jump through commits you haven't yet processed (so 0 -N would recurse N times). That being said, it seems like we could also rewrite this function to be iterative without too much trouble. Done in PR !
That's quite possible actually. The issue I was trying to diagnose was high CPU usage on an app that has spreadsheet like functionality, i.e. lots of components so I was trying to see exactly what was taking all the CPU time. Thanks for the PR. Hopefully next time this crops up it will solve it.
Great Should be released sometime in the next few days.

const commitTrees = ((rootToCommitTreeMap.get( rootID, ): any): Array<CommitTree>); if (commitIndex < commitTrees.length) { return commitTrees[commitIndex]; }

} const {operations} = dataForRoot; <ins> if (operations.length <= commitIndex) { throw Error( `getCommitTree(): Invalid commit "${commitIndex}" for root "${rootID}". There are only "${operations.length}" commits.`, ); } </ins> <del> // Commits are generated sequentially and cached. // If this is the very first commit, start with the cached snapshot and apply the first mutation. // Otherwise load (or generate) the previous commit and append a mutation to it. if (commitIndex === 0) { const nodes = new Map(); // Construct the initial tree. recursivelyInitializeTree(rootID, 0, nodes, dataForRoot); </del> <ins> let commitTree: CommitTree = ((null: any): CommitTree); for (let index = commitTrees.length; index <= commitIndex; index++) { // Commits are generated sequentially and cached. // If this is the very first commit, start with the cached snapshot and apply the first mutation. // Otherwise load (or generate) the previous commit and append a mutation to it. if (index === 0) { const nodes = new Map(); </ins> <del> // Mutate the tree if (operations != null && commitIndex < operations.length) { const commitTree = updateTree({nodes, rootID}, operations[commitIndex]); </del> <ins> // Construct the initial tree. recursivelyInitializeTree(rootID, 0, nodes, dataForRoot); </ins> <del> if (__DEBUG__) { __printTree(commitTree); } </del> <ins> // Mutate the tree if (operations != null && index < operations.length) { commitTree = updateTree({nodes, rootID}, operations[index]); </ins> <del> commitTrees.push(commitTree); return commitTree; } } else { const previousCommitTree = getCommitTree({ commitIndex: commitIndex - 1, profilerStore, rootID, }); </del> <ins> if (__DEBUG__) { __printTree(commitTree); } </ins> <del> if (operations != null && commitIndex < operations.length) { const commitTree = updateTree( previousCommitTree, operations[commitIndex], ); </del> <ins> commitTrees.push(commitTree); } } else { const previousCommitTree = commitTrees[index - 1]; commitTree = updateTree(previousCommitTree, operations[index]); </ins> if (__DEBUG__) { __printTree(commitTree); } commitTrees.push(commitTree); <del> return commitTree; </del> } } <del> throw Error( `getCommitTree(): Unable to reconstruct tree for root "${rootID}" and commit "${commitIndex}"`, ); </del> <ins> return commitTree; </ins> } function recursivelyInitializeTree(


Question:
After updating react-dom to version 17 the build now includes () which isn't supported by ie11 without polyfilling. Coming from this line. Tested with just the default cra production build to make sure it wasn't a problem with my webpack config and the same issue. Tested using CRA on version 16.9.8 of react and react-dom which works with the production build for ie11.
Confirmed with https://csb-hznfc- (built from ) which errors with "SCRIPT438: Object doesn't support property or method 'fill'".
Any chance you could confirm the fix on a real IE
Gonna wait to see if a few more bugs get reported in the next few hours. Then will cut a patch.
Should be fixed in 17.0.1.

} export function createLaneMap<T>(initial: T): LaneMap<T> { <del> return new Array(TotalLanes).fill(initial); </del> <ins> // Intentionally pushing one by one. // https://v8.dev/blog/elements-kinds#avoid-creating-holes const laneMap = []; for (let i = 0; i < TotalLanes; i++) { laneMap.push(initial); } return laneMap; </ins> } export function markRootUpdated(


Question:
This is a weird one. Basically, if you add an event listener to the document in an effect that was triggered by an event. e.g. toggles some state, which triggers an effect, which adds a handler to the document. In the normal case the new event handler will "miss" the triggering event, e.g. the click handler won't respond to the click event that triggered it being (omg). HOWEVER, if you render a portal first, the timing changes slightly and the event handler will see the current event. React version: 17 the "show Message" button to see a message toggle in and out the "Render Portal" button (see a portal rendered into the body) the "show Message" button again and notice nothing happens The reason for the final behavior is the click event both opens and closes the message, (calls set state twice) <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: That they be consistent
17 only?
17 only! downstream issue
well tbh maybe this was present but not observable since before 17 you couldn't attach an event listener "higher up" so there wasn't any way to get in front of the current event
What sounds like a bug here is that is called synchronously at all. It should normally be deferred — which would avoid this issue. So it sounds like there's an unexpected effect flush. Would be nice to dig into why.
I'm sooo confused. I can't reproduce this anymore. The only thing I did was to update Chrome...
Can you still repro it?
bah sorry i was goofing around trying to find a workaround and didn't realize it was saving instead of forking. It should be back to being reproducible
Ok at least I can still sleep at night
What happens here is that the native event bubbles: On the root container On the body (portal target) This is why we get into dispatchEvent twice. Root container pass schedules an effect, and body pass flushes it. Seems like a bug that we flush the effect in this case.
To follow up on this — it does seem like a bug but we can't commit to prioritizing it at the moment. There will be a bunch of work done to clean up and simplify related parts of the code in the coming months so we'll likely address it then. Have you found any userland workaround, or is this a hard blocker for you?
We've got a workaround that's simple and effective in theory . Need to let folks test it out a bit though. Alternatively I think adding listeners in a would work albeit pretty annoying to manage in an effect. For anyone looking, our current workaround is
What I noticed is that for an everything works fine but an actual user click causes the issue described: Edit: I think I'm try attaching a capture listener as well and then check in the bubble event listener if I also captured the event. That fixes the problem at least for mounts in the bubble phase. That looks promising so far: Edit2: Bisecting releases leads to good: 0.0.0-experimental- bad: 0.0.0-experimental- I used experimental releases since the release channel was released less often in that time. So the bug got introduced in Edit3: I don't think the timing of effects changed between 16 and 17. Looks like the timing of events changed due to the changes to the event delegation system. If you add the native listener to instead of , the code works fine. Edit4: ~When the portal is rendered into react attaches its event delegator onto the If I remove that event handler the message can be displayed again.~ See Edit5: Last bit: What makes this bug hard to track down with tests is that you naturally use but within React does not flush discrete updates. Though this is already documented in I'm generally suprised that passive effects are flushed synchronously at all but this does seem to be intended
It seems to me that the assertions in are not correct. The update that is scheduled in the passive effect is deferred as intended when flushing sync but the effect itself should not run when flushing synchronously. IMO would make more sense here. The test comment acknowledges that this is the opposite order and it seems to me that this issue is a good example why this order is problematic: Any side-effect that touches the DOM directly is out-of-order.
Not sure about the intended behaviour but it seems like having the following solve your issue (at least temporarely): On step 3, it displays the message correctly
You can also fix the issue by wrapping in a , like so:
Is there a fix in progress, for upcoming versions, for this bug? I am facing this issue , which cant be resolved because of this.
Could you explain in the Material-UI issue why this can't be resolved for you? We were under the impression that we worked around this bug for our specific usage. For updates on a fix, is the latest update. From what I gather the team is already experimenting with potential fixes. You can subscribe to this () github issue to get notified about updates. Asking for updates does not speed up delivery of said update.
The team has taken a closer look at this now that the related refactors are landing. We can't fix it in a general case without relying on some heuristic. Making all effects synchronous would be bad. Making all of them asynchronous also doesn't work because sometimes we need to flush earlier. The need to flush earlier relates to handling discrete events (like click) that need to be able to observe the already flushed state. A reasonable compromise is to make them synchronous at the end of discrete events (such as click), but asynchronous in other cases. This mirrors the recent changes we've made to state updates in Concurrent Mode to make it easier to adopt. So we this heuristic in Concurrent Mode: I checked that this issue in Concurrent Mode with the latest master commit and now consistently does not show the message (because clicks lead to synchronous effects). We've considered backporting this behavior to React 17. But at this point it's very risky because it's such a subtle change. It's also risky because it would be the first time that we rely on -based heuristics outside of Concurrent Mode. So it's kind of a new territory. Given that it's easy to work around, it doesn't seem like this risk is warranted in React 17. So we've concluded that, while unfortunate, it is safer to not try to fix it in React 17. But Concurrent Mode will have a more predictable behavior here. (Note that it's also quite likely that React 16 also had cases with over-flushing, but triggered under different conditions.) I know this isn't the resolution that most people were hoping for.
Bug; Still clickAwayListener tests fails using React testing library. It seems because of react18.

// TODO: These flags are hard-coded to the default values used in open source. // Update the tests so that they pass in either mode, then set these // to __VARIANT__. <ins> export const enableTrustedTypesIntegration = false; </ins> export const disableSchedulerTimeoutBasedOnReactExpirationTime = false; export const disableNativeComponentFrames = false; // You probably *don't* want to add more hardcoded ones.

export const { disableInputAttributeSyncing, <ins> enableTrustedTypesIntegration, </ins> disableSchedulerTimeoutBasedOnReactExpirationTime, warnAboutSpreadingKeyToJSX, replayFailedUnitOfWorkWithInvokeGuardedCallback,

export const enableUseEffectEventHook = true; export const enableHostSingletons = true; export const enableClientRenderFallbackOnTextMismatch = false; <del> export const enableTrustedTypesIntegration = false; </del> // Logs additional User Timing API marks for use with an experimental profiling tool. export const enableSchedulingProfiler: boolean =


Question:
When I use DevTools to select an element on the page, it can't jump/find it. It also doesn't show it in the Components page. This was checked by finding its parent and checking the children, non of the newly generated ones are there. As a probably related bug Profiler doesn't show/record the changes. React version: 16.13.1 React-dom version: 16.13.1 Parcel: 2.0.0-beta.1 a parent element a child element (A) conditional rendering () "hide" A now shows and select B using Chrome Dev Tools's "Select an element in the page to inspect it" nowhere/Can't find it manually in the list. ! In this example, I demonstrate that it works on the Search Bar (light grey bar) which is the TextField=InputBase tree, and the Container that contains the search & images and how hovering over the image doesn't do anything. I then click on the image and nothing happens & the state panel on the right of Dev Tools empties itself. Can't find newly rendered components in React Dev Tools Components panel Being able to find the newly rendered components in React Dev Tools Components panel
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. Screenshots or videos can also be helpful if they help provide context on how to repro the bug. Here are some tips for providing a minimal example:
how "complex"/big of a repo is allowed for me to link to? As so far I have had 0 luck replicating a basic example on codesandbox as it behaves as it should.
The smaller it is, the better chance someone will be able to look at it and find/fix the problem.
So it appears the issue is Google-Analytics. If I remove the code it is fine, add it, and it breaks. As such I have created a branch where I have removed basically all of the code except what is really needed to show this breaking. In order to repo repo i start to HTTP://localhost:1234 into Chrome Dev Tools (Ctrl+Shift+i) to components (Figure 1) page that only App/Homepage/OfficialServers/Guilds show (Figure 1) to lines 10 to 23 aka the GA stuff will rebuild and reload page back to Chrome Dev Tools there is a lot more content (Figure 2) Figure 1 ! Figure 2 ! Hopefully, this is more helpful :)
Thanks for the info :) I'll tag this as "needs investigation" in case anyone has bandwidth to dig in.
Thanks man :)
I can't reproduce the broken behavior your screenshot shows using this repo. For me, the nested and components are visible with GA or without. Passing the issue back to you for more repro instructions. You might need to dig in and see if any errors are being thrown by DevTools. There might also be another web extension you have installed that is making this happen.
Interesting note, when I just swapped branch to it, it worked fine (aka didn't break), but after running a it broke again properly. I had a range of extensions (not mentioning as it currently doesn't seem needed), so I disabled them all except React Dev Tools to obviously show the results. But it still broke. I then swapped to checking the Console, below you can see the results of it. This was after clearing the console then F5. ! I am not going to link the files as they are massive, but they start with (top down) Hope this helps
I don't really see anything useful in that console. Am I suppose to? The source map warning is unrelated. Also not sure I understand how those JSON files are supposed to be related, sorry.
Honestly same, I was just praying that something in there made sense for what or why this is happening at the moment. I am currently unsure of what to test tbh. Could it be browser dependant? I am currently testing this all in Chrome: 86.0.4240.75 maybe it doesn't occur in other browsers?
Sorry, what I meant was that I don't really understand your latest comment. I don't think the JSON files are useful/usable by me in any way to reproduce this issue? And the console warnings are definitely not related to what you're reporting. I am testing on OS X with Chrome 86.0.4240.111.
I was able to repro this with a fresh install of the linked repo. It seems that any script tag after the one that loads the react app module will cause this issue, in this case . I removed GA entirely and just a simple console log. Example here: And the issue still occurred. Moving the script above resolves it: I know that the React documentation recommends putting the , but I don't think this is expected behavior for the dev tools since the rest of the application works fine. But it's worth noting that putting or with the script tag will make browsers load that script last. I also removed the API call and had it load the data by default, and could see everything in the components tree. So this probably isn't an issue related conditional rendering, but rather it's ability to catch re-renders and updates when the react module isn't the last script the browser loads.
I'm confused by this statement. The docs section you linked to just shows loading React before loading your component code that uses React– and that's only applicable if you're using UMD builds (loading code into the global/window namespace). I am not aware of any reason why additional tags being present in the page should have any impact on React DevTools (and I don't see the behavior being described when running the repro app).
Update, I was using Firefox 81.0.2 and same issue. Also I am on Windows, but I doubt that is the issue. Doing a was able to trigger it. I was also able to mirror the fix that had, by moving the under the GA code.
You're right, my apologies! It really shouldn't, I was just reporting what I was experiencing when trying to reproduce the issue. It so far has consistently worked when no other script follows in execution order, but fails when one does. I am on macOS with Chrome 86.0.4240.111. Also tried it on Windows, experienced the same issue. I tried to recreate the issue on codesandbox, but was unable to. I did notice that the version of React DevTools available on codesandbox is , while I'm using , so that could be why it's difficult to get this behavior on there!
Just tried the steps again and I still can't repro the issue. Might be worth pointing out that my app doesn't look anything like yours. Your screenshot shows: But when I run the repro app, I see: I assume this is expected because it's just a reduced repro case, but just wanted to clarify. I'm going to need one of you to dig into this and provide some more info. I can't trigger the problem, so there's not much I can do on this end to help. Does the console show any errors that might be related? (None of the ones in the screenshot above looked related but are there others?) If you detach the browser DevTools panel and open a second DevTools– does that DevTools have any errors (coming from one of your installed extensions) that might be related? !
I think the link they shared for the repo included a specific commit that they put the reduced code, instead of it being in master. Did you checkout the commit they shared @ ? Just wondering since your example looks different from what I got when trying to repro as well! For me, there were no related errors in the console or the devtools.
I followed the repro steps above, exactly: I assume that you did as well? If you have to do something else to repro this, that would be helpful to know.
They mentioned in their comment they created a new branch, so I guess I expanded step 1 from their steps into: - -
Thanks Let me try that.
Ah! That was the missing step. This is interesting. Checking out that branch: If I load the page, then open DevTools, it looks fine. If I open DevTools and then (re)load the page, some components are missing.
Interesting to note that I stepped all the way back to DevTools v4.0.0 and this bug still happens. This is definitely not a recent regression.
It's also interesting to note that I can't repro this with the DevTools extension detached (and logging debug info) only when it's docked to the bottom and I reload the page after it was already open. That's going to make it a little harder to track down.
I've been able to reduce the repro to the following: Unfortunately I have not been able to reproduce the failing behavior in one of our integration tests. Still, a small repro is very promising. Going to dig into the actual code now and see what's breaking :smile:
Very nice work :D Glad I wasn't losing the plot, weird how picky it is in regards to the DevTools behaviour
I think this bug is actually being caused by Fast Refresh bailing out without calling the decorated DevTools hook: Although it seems sensitive to timing so I'm having trouble catching it in the debugger.
Conceptually, it's possible for Fast Refresh to intercept a renderer that it isn't compatible with: In which case, subsequent commits from react-dom will effectively block DevTools entirely: This looks wrong. FR should always pass through to DevTools.
Thanks for the fix :)

}, "engines": { "node": ">=0.10.0" <ins> }, "devDependencies": { "react-16-8": "npm:react@16.8.0", "react-dom-16-8": "npm:react-dom@16.8.0" </ins> } <del> } </del> <ins> } </ins>  No newline at end of file

didError: boolean, ) { const helpers = helpersByRendererID.get(id); <del> if (helpers === undefined) { return; } helpersByRoot.set(root, helpers); const current = root.current; const alternate = current.alternate; // We need to determine whether this root has just (un)mounted. // This logic is copy-pasted from similar logic in the DevTools backend. // If this breaks with some refactoring, you'll want to update DevTools too. if (alternate !== null) { const wasMounted = alternate.memoizedState != null && alternate.memoizedState.element != null; const isMounted = current.memoizedState != null && current.memoizedState.element != null; if (!wasMounted && isMounted) { </del> <ins> if (helpers !== undefined) { helpersByRoot.set(root, helpers); const current = root.current; const alternate = current.alternate; // We need to determine whether this root has just (un)mounted. // This logic is copy-pasted from similar logic in the DevTools backend. // If this breaks with some refactoring, you'll want to update DevTools too. if (alternate !== null) { const wasMounted = alternate.memoizedState != null && alternate.memoizedState.element != null; const isMounted = current.memoizedState != null && current.memoizedState.element != null; if (!wasMounted && isMounted) { // Mount a new root. mountedRoots.add(root); failedRoots.delete(root); } else if (wasMounted && isMounted) { // Update an existing root. // This doesn't affect our mounted root Set. } else if (wasMounted && !isMounted) { // Unmount an existing root. mountedRoots.delete(root); if (didError) { // We'll remount it on future edits. failedRoots.add(root); } else { helpersByRoot.delete(root); } } else if (!wasMounted && !isMounted) { if (didError) { // We'll remount it on future edits. failedRoots.add(root); } } } else { </ins> // Mount a new root. mountedRoots.add(root); <del> failedRoots.delete(root); } else if (wasMounted && isMounted) { // Update an existing root. // This doesn't affect our mounted root Set. } else if (wasMounted && !isMounted) { // Unmount an existing root. mountedRoots.delete(root); if (didError) { // We'll remount it on future edits. failedRoots.add(root); } else { helpersByRoot.delete(root); } } else if (!wasMounted && !isMounted) { if (didError) { // We'll remount it on future edits. failedRoots.add(root); } </del> } <del> } else { // Mount a new root. mountedRoots.add(root); </del> } <ins> // Always call the decorated DevTools hook. </ins> return oldOnCommitFiberRoot.apply(this, arguments); }; } else {

} }); <del> // This simulates the scenario in https://github.com/facebook/react/issues/17626. </del> <ins> function initFauxDevToolsHook() { const onCommitFiberRoot = jest.fn(); const onCommitFiberUnmount = jest.fn(); let idCounter = 0; const renderers = new Map(); // This is a minimal shim for the global hook installed by DevTools. // The real one is in packages/react-devtools-shared/src/hook.js. global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = { renderers, supportsFiber: true, inject(renderer) { const id = ++idCounter; renderers.set(id, renderer); return id; }, onCommitFiberRoot, onCommitFiberUnmount, }; } // This simulates the scenario in https://github.com/facebook/react/issues/17626 </ins> it('can inject the runtime after the renderer executes', () => { if (__DEV__) { <del> // This is a minimal shim for the global hook installed by DevTools. // The real one is in packages/react-devtools-shared/src/hook.js. let idCounter = 0; const renderers = new Map(); global.__REACT_DEVTOOLS_GLOBAL_HOOK__ = { renderers, supportsFiber: true, inject(renderer) { const id = ++idCounter; renderers.set(id, renderer); return id; }, onCommitFiberRoot() {}, onCommitFiberUnmount() {}, }; </del> <ins> initFauxDevToolsHook(); </ins> // Load these first, as if they're coming from a CDN. jest.resetModules();

expect(el.style.color).toBe('red'); } });  // This simulates the scenario in https://github.com/facebook/react/issues/20100 it('does not block DevTools when an unsupported renderer is injected', () => { if (__DEV__) { initFauxDevToolsHook(); const onCommitFiberRoot = global.__REACT_DEVTOOLS_GLOBAL_HOOK__.onCommitFiberRoot; // Redirect all React/ReactDOM requires to v16.8.0 // This version predates Fast Refresh support. jest.mock('react', () => jest.requireActual('react-16-8')); jest.mock('react-dom', () => jest.requireActual('react-dom-16-8')); // Load React and company. jest.resetModules(); React = require('react'); ReactDOM = require('react-dom'); Scheduler = require('scheduler'); // Important! Inject into the global hook *after* ReactDOM runs: ReactFreshRuntime = require('react-refresh/runtime'); ReactFreshRuntime.injectIntoGlobalHook(global); render(() => { function Hello() { return
Hi!
; } $RefreshReg$(Hello, 'Hello'); return Hello; }); expect(onCommitFiberRoot).toHaveBeenCalled(); } });  });

object-assign "^4.1.0" prop-types "^15.5.10" <ins> "react-16-8@npm:react@16.8.0": version "16.8.0" resolved "https://registry.yarnpkg.com/react/-/react-16.8.0.tgz#8533f0e4af818f448a276eae71681d09e8dd970a" integrity sha512-g+nikW2D48kqgWSPwNo0NH9tIGG3DsQFlrtrQ1kj6W77z5ahyIHG0w8kPpz4Sdj6gyLnz0lEd/xsjOoGge2MYQ== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" prop-types "^15.6.2" scheduler "^0.13.0" </ins> "react-dom-15@npm:react-dom@^15": version "15.6.2" resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-15.6.2.tgz#41cfadf693b757faf2708443a1d1fd5a02bef730"

object-assign "^4.1.0" prop-types "^15.5.10" <ins> "react-dom-16-8@npm:react-dom@16.8.0": version "16.8.0" resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-16.8.0.tgz#18f28d4be3571ed206672a267c66dd083145a9c4" integrity sha512-dBzoAGYZpW9Yggp+CzBPC7q1HmWSeRc93DWrwbskmG1eHJWznZB/p0l/Sm+69leIGUS91AXPB/qB3WcPnKx8Sw== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" prop-types "^15.6.2" scheduler "^0.13.0" </ins> react-is@^16.12.0, react-is@^16.8.1: version "16.13.1" resolved "https://registry.yarnpkg.com/react-is/-/react-is-16.13.1.tgz#789729a4dc36de2999dc156dd6c1d9c18cea56a4"

loose-envify "^1.1.0" object-assign "^4.1.1" <ins> scheduler@^0.13.0: version "0.13.6" resolved "https://registry.yarnpkg.com/scheduler/-/scheduler-0.13.6.tgz#466a4ec332467b31a91b9bf74e5347072e4cd889" integrity sha512-IWnObHt413ucAYKsD9J1QShUKkbKLQQHdxRyw73sw4FN26iWr3DY/H34xGPe4nmL1DwXyWmSWmMrA9TfQbE/XQ== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" </ins> schema-utils@^1.0.0: version "1.0.0" resolved "https://registry.yarnpkg.com/schema-utils/-/schema-utils-1.0.0.tgz#0b79a93204d7b600d4b2850d1f66c2a34951c770"


Question:
React version: . . Note the React peer dependency error. Notably, this currently affects (see ). will refuse to perform this installation entirely. peer-depends on whereas peer-depends on , which is generally considered a breaking change in a minor version. This might have been an oversight in how interacted with (It's considered a breaking change because a like the below should always result in a valid install.) Here are two potential solutions: Cut a release of that peer-depends on , strictly widening the peer dep range from that of 1.4.1. Cut a major release of that peer-depends on , and cut a release of that reverts its peer dependency to .
Happy to take a PR that fixes this by making the range more permissible. I think we need a bump after that to increase the major and simply keep 17-only. If you send a PR like this, please check if any of the other React packages had a similar problem with 17.
If you send a PR like this, please check if any of the other React packages had a similar problem with 17. Sure, I'll send a PR. I noticed a few similar cases in but they all seemed to be for "internal"/"experimental" packages: - - - - - Do you care about fixing any of these since they (AFAIK) don't really have public consumers?
(Retitling per your comment and my reply Sorry about that.)


Question:
macOS 11.0.1 Big Sur, on an Apple Silicon (M1) chip React 17.0.1 React DevTools 4.10.1, running in standalone mode via Electron 11.1.0 (darwin-arm64 build) New project using create-react-app . with the useScript hook to add the <scripttag required by React DevTools. React DevTools to a project with (or yarn). -devtools expects Electron 9.x.x; however builds for darwin-arm64 are only available for 11.1.0. Installation fails with: Link to code example: Workarounds are ; however a 11.1.0 build is required. Bump the version in so this works out of the box.
Want to submit a PR (and test the bump)?
I can look into this
Okay.
Just wanted to add that bumping the version works well. <img width="1027" alt="image" src="https://user-"
Hi are you working on this? If not, I'd like to take this issue.
Sure im looking into another issue you can take it up!
I can update electron package version
[devtools] Bump electron version from 9.1.0 to 11.1.0 for darwin-arm64 builds
So, I think need close this issue
I think they'll close it once the PR is merged
How can we install this bumped version from github pull request? without waiting to be merged?
You'll have to clone my forked repo and build from source. You can find the instructions to build
Can someone please tell how to use resolutions ? I am macbook pro m1 and when I hit the command -It gives the following error What I tried is I downloaded the react devtools 4.10.1 in my local system and tried install it using Then I installed react-native-debugger and then again got the same issue. Unsupported DevTools backend version You are running react-devtools version 4.13.4-. This requires bridge protocol version 1. However the current backend version uses bridge protocol version 0. To fix this, downgrade the DevTools NPM package:
My dirty workaround, things seem to work fine on my M1 machine: Install Electron 11 globally Install react-devtools without the binary download Remove the existing folder and in the react-devtools electro module - Symlink the global electron installation to the react-devtools electron module installation - I also had to update the package inside my global installation to 4.11.0 (could use the same symlinking logic there too I guess)
thanks for me, just the first two steps worked on my M1 machine Install Electron 11 globally npm i -g electron Install react-devtools without the binary download ELECTRONSKIPBINARY_DOWNLOAD=1 npm i -g react-devtools
I had to follow the steps in mixed with 's steps. I'm using a mac M1 which gives the error So I used the following modified steps:
The response by works perfectly. Thanks. Just replace by the wanted version. For example for me i wanted react-devtools 4.10.4 (the inspector couldn't inspect anything up this version) So i just changed and .

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.3.538.tgz#15226638ee9db5d8e74f4c860cef6078d8e1e871" integrity sha512-rlyYXLlOoZkJuvY4AJXUpP7CHRVtwZz311HPVoEO1UHo/kqDCsP1pNas0A9paZuPEiYGdLwrjllF2hs69NEaTw== <del> electron@^9.1.0: version "9.1.0" resolved "https://registry.yarnpkg.com/electron/-/electron-9.1.0.tgz#ca77600c9e4cd591298c340e013384114d3d8d05" integrity sha512-VRAF8KX1m0py9I9sf0kw1kWfeC87mlscfFcbcRdLBsNJ44/GrJhi3+E8rKbpHUeZNQxsPaVA5Zu5Lxb6dV/scQ== </del> <ins> electron@^11.1.0: version "11.1.1" resolved "https://registry.yarnpkg.com/electron/-/electron-11.1.1.tgz#188f036f8282798398dca9513e9bb3b10213e3aa" integrity sha512-tlbex3xosJgfileN6BAQRotevPRXB/wQIq48QeQ08tUJJrXwE72c8smsM/hbHx5eDgnbfJ2G3a60PmRjHU2NhA== </ins> dependencies: "@electron/get" "^1.0.1" "@types/node" "^12.0.12"


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 17.0.1 the project: react dev tools and set the highlight updates when components render option. changes to the todos no updates are displayed via React dev tools <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --currently, updates are only displayed if the react component is not memoized. all react components should show their updates regardless of memoization.
any idea who I should ping to get some eyes on this?
No one needs to be pinged. We review GitHub issues as we have bandwidth. If you'd like to contribute a bug fix, those are welcome.
Sure, do you have an idea where I might look to investigate something like this? It would be my first time contributing to that code so it'd be greatly helpful if someone could point me in the general direction.
a start would be reading this Then you can read through the of the to get an idea of to start and debug the dev tools locally. Haven't submitted anything myself, but that's how I'd start.

if ( elementType === ElementTypeFunction || elementType === ElementTypeClass || <del> elementType === ElementTypeContext </del> <ins> elementType === ElementTypeContext || elementType === ElementTypeMemo || elementType === ElementTypeForwardRef </ins> ) { // Otherwise if this is a traced ancestor, flag for the nearest host descendant(s). traceNearestHostComponentUpdate = didFiberRender(


Question:
React version: 17.0.1 Setup eslint with as parser Cast a function passed to Link to code example: The following error was reported The rule should interpret the function argument correctly and know that it is already inline.
It looks like it is something that would be easy to support, but the question is: why would you do that?
Heh, a fair question. In my case, I needed it in order to support generics for a hook that helps manage state for asynchronous calls like mutations: Without the cast, TS doesn't know that the shape of the args object is the same. On the return statement, TS warns: This remains true even if I make the args a generic type too, so I think the issue is unavoidable.
TS is correct there. A function that has the same input type & return type as is not assignable to . might have other properties attached to it as well, which won't be attached to . For your particular situation, the type for can be a function that has the same argument & return types as , but should not be . Casting it as is lying to typescript.
Ahhh. Thanks With that hint I was able to fix my types and obviate the cast. That said, I would recommend keeping this issue open, since there will always be cases where folks will have to resort to casts like these, whether due to limitations in TS's expressiveness or (as in this case and I suspect most cases) one's ability to understand the type complexities and specify the types correctly. Sadly, not everyone has access to a to help them out when the types get complex.

} `, }, <ins> { code: normalizeIndent` function App(props) { React.useEffect((() => { console.log(props.test); }) as any, [props.test]); } `, }, </ins> ], invalid: [ {

isEffect, ); return; // Handled <ins> case 'TSAsExpression': visitFunctionWithDependencies( callback.expression, declaredDependenciesNode, reactiveHook, reactiveHookName, isEffect, ); return; // Handled </ins> case 'Identifier': if (!declaredDependenciesNode) { // No deps, no problems.


Question:
React version: v17.0.1 http://localhost:3000 in Chrome 88 or 89, regular or Incognito mode DevTools: the warning is displayed Link to code example: https://react- Warning: No warning will be shown. As the warning shows, Chrome will require cross-origin isolation starting version 91 in order to use SharedArrayBuffer. To enable cross-origin isolation, the page needs to be loaded with COOP and COEP headers which I believe is out of React's control. You can learn more about this at As it's confusing for React users to see this warning every time they open the page, I'd propose two things: the message by using SAB only when cross-origin isolation is enabled. You can check it by boolean flag. that the page needs to send COOP and COEP headers to profile performance using SharedArrayBuffer. You can find an actionable guide here: The problematic code is here: FWIW, with cross-origin isolation, you'll be able to use too. cc:
I've created a PR to fix this.
Will this be back-ported to React 16? I have projects that can't upgrade yet because they rely on packages that aren't fully compatible with React 17 yet (e.g. Material-UI).
My workaround is to put a script in the file: <scriptif (!crossOriginIsolated) SharedArrayBuffer = ArrayBuffer </script
Why is this closed? just need to publish the solution?
Because the fix has been merged to master.
We don’t generally backport anything except critical security fixes. My understanding is that the only problem here is a warning. Not that something would actually break. Do you have evidence to the contrary?
Starting Chrome 91, will return on environments without cross-origin isolation. This shouldn't be a breaking change for React as far as I can tell. FWIW, you can emulate how it will behave in Chrome by launching it with a command line flag . Here's instructions:
React 17.0.2 was released with removed dependency on so this should be resolved.
We don't plan to backport this since there is no real breaking change for React here.
For later versions that Fix will not be available?
You mean for earlier ones? No, but also nothing would break. You can ignore the message.
use http-proxy-middleware package but works only in dev mode, so not in production. I'd suggest using a Nginx as proxy and inject the 2 http headers.

let runIdCounter: number = 0; let mainThreadIdCounter: number = 0; <ins> const isEnabledSharedArrayBuffer = // $FlowFixMe Flow doesn't know about SharedArrayBuffer typeof SharedArrayBuffer === 'function' && // We only use SharedArrayBuffer when cross origin isolation is enabled. typeof window !== 'undefined' && window.crossOriginIsolated === true; </ins> const profilingStateSize = 4; export const sharedProfilingBuffer = enableProfiling <del> ? // $FlowFixMe Flow doesn't know about SharedArrayBuffer typeof SharedArrayBuffer === 'function' </del> <ins> ? isEnabledSharedArrayBuffer </ins> ? new SharedArrayBuffer(profilingStateSize * Int32Array.BYTES_PER_ELEMENT) <del> : // $FlowFixMe Flow doesn't know about ArrayBuffer typeof ArrayBuffer === 'function' </del> <ins> : typeof ArrayBuffer === 'function' </ins> ? new ArrayBuffer(profilingStateSize * Int32Array.BYTES_PER_ELEMENT) : null // Don't crash the init path on IE9 : null;


Question:
This is not important but it seems that this if statement is superfluous since always returns a string.
Yeah, looks like maybe this got broken during a refactor (). Actually since we check the type right above, maybe the condition should have just been deleted entirely. (I don't remember this code very well.)
Hey, I'm gonna pick this up and try to get a PR through to tidy this :) This would be my first issue in this repo. I've given the contribution guidelines a read through, and so will do my best to follow all the CoC and best practices in there.
This issue is all yours I've the "good first issue (taken)" label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let me know so that I can remove the label and free it up for someone else to claim. Cheers!
Hey! Raised a PR for this. Couldn't find any unit tests that covered the function here, and I started to write a few, but thought that it was probably out of scope of this PR. Can definitely create some tests for this function if needed though!

: data.constructor.name, }; <del> if (typeof data[Symbol.iterator]) { // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); } </del> <ins> // TRICKY // Don't use [...spread] syntax for this purpose. // This project uses @babel/plugin-transform-spread in "loose" mode which only works with Array values. // Other types (e.g. typed arrays, Sets) will not spread correctly. Array.from(data).forEach( (item, i) => (unserializableValue[i] = dehydrate( item, cleaned, unserializable, path.concat([i]), isPathAllowed, isPathAllowedCheck ? 1 : level + 1, )), ); </ins> unserializable.push(path);


Question: I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.

} .PrimitiveHookNumber { <del> color: var(--color-component-badge-count-inverted); background-color: var(--color-component-badge-background-inverted); </del> <ins> background-color: var(--color-primitive-hook-badge-background); color: var(--color-primitive-hook-badge-text); </ins> font-size: var(--font-size-monospace-small); margin-right: 0.25rem; border-radius: 0.125rem;

updateStyleHelper(theme, 'color-expand-collapse-toggle', documentElements); updateStyleHelper(theme, 'color-link', documentElements); updateStyleHelper(theme, 'color-modal-background', documentElements); <ins> updateStyleHelper( theme, 'color-primitive-hook-badge-background', documentElements, ); updateStyleHelper(theme, 'color-primitive-hook-badge-text', documentElements); </ins> updateStyleHelper(theme, 'color-record-active', documentElements); updateStyleHelper(theme, 'color-record-hover', documentElements); updateStyleHelper(theme, 'color-record-inactive', documentElements);

--light-color-expand-collapse-toggle: #777d88; --light-color-link: #0000ff; --light-color-modal-background: rgba(255, 255, 255, 0.75); <ins> --light-color-primitive-hook-badge-background: #e5e5e5; --light-color-primitive-hook-badge-text: #5f6673; </ins> --light-color-record-active: #fc3a4b; --light-color-record-hover: #3578e5; --light-color-record-inactive: #0088fa;

--dark-color-expand-collapse-toggle: #8f949d; --dark-color-link: #61dafb; --dark-color-modal-background: rgba(0, 0, 0, 0.75); <ins> --dark-color-primitive-hook-badge-background: rgba(0, 0, 0, 0.25); --dark-color-primitive-hook-badge-text: rgba(255, 255, 255, 0.7); </ins> --dark-color-record-active: #fc3a4b; --dark-color-record-hover: #a2e9fc; --dark-color-record-inactive: #61dafb;


Question:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 16.x <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Nothing. It's part of WAI-ARIA 1.3
I guess the question is what React considers a "valid" aria prop: specific version (range) of Aria version with a (WR,CR,PR,REC) spec editors consider the aria prop that ever existed
Yeah, it seems they've support for this fairly recently.
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” React isn’t the source of truth for that information. It sounds like the job of a linter rather than something react should warn about.
I think it might be from a compiler.
It's from here:
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” The reason is that they're often misspelled so on the whole it's beneficial to warn for unknown ones. I'll merge the PR.
Fixed by Will appear in 18.

Get Started Download React v{{site.react_version}}   Get Started Download React v{{site.react_version}}


Question:
React version: 16.14.0, 17.0.2 aspectRatio via - no aspectRatio applied via className - aspectRatio applied Needs Chrome 79 or above: Link to code example: No aspectRatio rule applied: aspectRatio applied, here I'm adding it via a :
Yes, I have the same issue with another style property Basically I want to add or and it gets removed.
Try passing a string instead of number. React special cases numbers (to add the "px" suffix) and only doesn't for certain known attributes. So new ones sometimes need to be to this list if they shouldn't get a px suffix (most should):
Your issue is unrelated. Would you mind opening a separate issue for that thread? Basically try instead. I.e. double strings. It's confusing but CSS expects a JS string of a CSS string. This is similar to how you have to do in React but it's a little clearer there because it's a wrapper around it.
Thanks
how soon do you need this? Are you blocked?
no, no rush at all! Just something I stumbled upon. Thanks for the lightning-quick response though!

*/ export const isUnitlessNumber = { animationIterationCount: true, <ins> aspectRatio: true, </ins> borderImageOutset: true, borderImageSlice: true, borderImageWidth: true,


Question: flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.

export function flushSync<A, R>(fn: A => R, a: A): R { const prevExecutionContext = executionContext; <del> if ((prevExecutionContext & (RenderContext | CommitContext)) !== NoContext) { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } return fn(a); } </del> executionContext |= BatchedContext; const previousPriority = getCurrentUpdatePriority();

// Flush the immediate callbacks that were scheduled during this batch. // Note that this will happen even if batchedUpdates is higher up // the stack. <del> flushSyncCallbackQueue(); </del> <ins> if ((executionContext & (RenderContext | CommitContext)) === NoContext) { flushSyncCallbackQueue(); } else { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } } </ins> } }

<ins> let React; let ReactNoop; let Scheduler; let useState; let useEffect; describe('ReactFlushSync', () => { beforeEach(() => { jest.resetModules(); React = require('react'); ReactNoop = require('react-noop-renderer'); Scheduler = require('scheduler'); useState = React.useState; useEffect = React.useEffect; }); function Text({text}) { Scheduler.unstable_yieldValue(text); return text; } test('changes priority of updates in useEffect', async () => { function App() { const [syncState, setSyncState] = useState(0); const [state, setState] = useState(0); useEffect(() => { if (syncState !== 1) { setState(1); ReactNoop.flushSync(() => setSyncState(1)); } }, [syncState, state]); return <Text text={`${syncState}, ${state}`} />; } const root = ReactNoop.createRoot(); await ReactNoop.act(async () => { root.render(<App />); // This will yield right before the passive effect fires expect(Scheduler).toFlushUntilNextPaint(['0, 0']); // The passive effect will schedule a sync update and a normal update. // They should commit in two separate batches. First the sync one. expect(() => expect(Scheduler).toFlushUntilNextPaint(['1, 0']), ).toErrorDev('flushSync was called from inside a lifecycle method'); // The remaining update is not sync ReactNoop.flushSync(); expect(Scheduler).toHaveYielded([]); // Now flush it. expect(Scheduler).toFlushUntilNextPaint(['1, 1']); }); expect(root).toMatchRenderedOutput('1, 1'); }); }); </ins>


Question: We currently build DevTools to target Chrome 49 and Firefox 54. These are super old browser versions and they did not have full ES6 support, so the generated build is more bloated than it needs to be. DevTools uses most modern language features. Off the top of my head, the following features are used (basically everything but async and generator functions): The above min browser versions come from Assuming I'm not forgetting things, it looks like we'd need to target Chrome 60+ (released 2017-07-25) and Firefox 55+ (released 2017-04-18). This seems like a reasonable set of browsers to target. Interestingly enough, according to , but I think certain details (like spread in object literals) weren't included in the original spec and/or weren't until later. Note that we can't remove the IE 11 target from the backend yet due to Hermes (React Native) ES6 support but that should be doable by the end of the year given current engineering targets. But we could update the frontend target, as well as the targets for the extensions and the package. It would be good to increase the browser versions we target to at least the version numbers mentioned above, rebuild the DevTools, and compare bundle sizes and generated code.

"version": "4.10.1", "version_name": "4.10.1", <del> "minimum_chrome_version": "49", </del> <ins> "minimum_chrome_version": "60", </ins> "icons": { "16": "icons/16-production.png",

"applications": { "gecko": { "id": "@react-devtools", <del> "strict_min_version": "54.0" </del> <ins> "strict_min_version": "55.0" </ins> } },


Question:
React version: 17.0.2 React-refresh version: 0.10.0 This issue is similar to , but ignores default exported unnamed functions instead. As a code comment suggests, this is a known limitation: Would a fix be considered? Given the following files, making changes to doesn't trigger a re-render. module: module: Making changes to does not re-render the element in . The transformed module does not register the for refresh. Making changes to does re-render the element in .
This is intentional — even if we fix this case, we need some heuristic for other tools like lint rules. Why are you using this style? Functions should have names so that you get them in stack traces and so on.
Indeed, but then it becomes confusing: If there's no way around, this can be closed and I'll make a suggestion downstream to use The code comment mentioned above should then also be more explicit, replacing "currently" by "intentionally".
However, given that an ignored component prevents a refresh (), I haven't figured out yet whether this is an issue with itself or with . AFAIK, a code update of an ignored component should still trigger a refresh.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

} `, }, <ins> { code: normalizeIndent` export const notAComponent = () => { return () => { useState(); } } `, // TODO: this should error but doesn't. // errors: [functionError('use', 'notAComponent')], }, { code: normalizeIndent` export default () => { if (isVal) { useState(0); } } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, { code: normalizeIndent` function notAComponent() { return new Promise.then(() => { useState(); }); } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, </ins> ], invalid: [ {


Question:
Published has the following piece of code in : :roll_eyes:
FYI
Huh. That's no good.
This is because I accidentally put the module map in an map rather than a map. Oops.
Fix published in 4.11.1
Thanks!

{ "name": "react-devtools-inline", <del> "version": "4.11.0", </del> <ins> "version": "4.11.1", </ins> "description": "Embed react-devtools within a website", "license": "MIT", "main": "./dist/backend.js",

react: 'react', // TODO: Once this package is published, remove the external // 'react-debug-tools': 'react-debug-tools', <del> 'react-devtools-feature-flags': resolveFeatureFlags('inline'), </del> 'react-dom': 'react-dom', 'react-is': 'react-is', scheduler: 'scheduler', }, <ins> resolve: { alias: { 'react-devtools-feature-flags': resolveFeatureFlags('inline'), }, }, </ins> optimization: { minimize: false, },

<!-- Upcoming changes go here --> </details> <ins> ## 4.11.1 (April 11, 2021) #### Bugfix * Fixed broken import in `react-devtools-inline` for feature flags file ([bvaughn](https://github.com/bvaughn) in [#21235](https://github.com/facebook/react/issues/21235)) </ins> ## 4.11.0 (April 9, 2021) #### Bugfix * `$r` should contain hooks property when it is `forwardRef` or `memo` component  ([meowtec](https://github.com/meowtec) in [#20626](https://github.com/facebook/react/pull/20626))


Question:
This is a followup issue for pmndrs/react-three-fiber From my understanding of , the DevTools parse the version number advertised by the renderer in to select how to parse the internal fiber object. Unfortunately this means that third-party renderers that advertise a version lower than the equivalent React version for the release they are using get misclassified: for instance is using which is equivalent to , and since major version is much lower than it uses the default values for the enum which in turns lead to getting identified as and hook inspection being unavailable. A short term solution for renderers is to advertise a React-compatible version number, but ideally this is an implementation detail of the devtools that users of should not have to be aware of (also this means the version number displayed in the devtools is wrong). I'm not sure I'm familiar enough with the internals of the devtools to open a PR for this, but since the version parsing logic is used to detect features that are internal to anyway I guess a solution would be to have the Reconciler package add its own value for the constant along with the parameters sent to the devtools backend, and have the devtools use this string if its available over the renderer version.
Once and land (and get released) newer versions of the reconciler will inject its own version (to be used instead of the renderer version). Unfortunately this won't help you until you upgrade.

findHostInstancesForRefresh, } from './ReactFiberHotReloading.new'; import {markRenderScheduled} from './SchedulingProfiler'; <ins> import ReactVersion from 'shared/ReactVersion'; </ins> export {registerMutableSourceForHydration} from './ReactMutableSource.new'; export {createPortal} from './ReactPortal'; export {

findHostInstancesForRefresh, } from './ReactFiberHotReloading.old'; import {markRenderScheduled} from './SchedulingProfiler'; <ins> import ReactVersion from 'shared/ReactVersion'; </ins> export {registerMutableSourceForHydration} from './ReactMutableSource.old'; export {createPortal} from './ReactPortal'; export {

setRefreshHandler: __DEV__ ? setRefreshHandler : null, // Enables DevTools to append owner stacks to error messages in DEV mode. getCurrentFiber: __DEV__ ? getCurrentFiberForDevTools : null, <ins> // Enables DevTools to detect reconciler version rather than renderer version // which may not match for third party renderers. reconcilerVersion: ReactVersion, </ins> }); }


Question:
Describe what you were doing when the bug occurred: Please do not remove the text below this line DevTools version: 4.11.0- Call stack: at chrome- at Map.forEach (<anonymous) at RankedChartBuildergetChartData (chrome-) at ProfilingCacheProfilingCache.getRankedChartData (chrome-) at CommitRankedAutoSizer (chrome-) at Rh (chrome-) at Ci (chrome-) at uk (chrome-) at tk (chrome-) at qk (chrome-) Component stack: at CommitRankedAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevTools_DevTools (chrome-)
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. Screenshots or videos can also be helpful if they help provide context on how to repro the bug. Here are some tips for providing a minimal example:
Just saw this same stacktrace running devtools . I don't know how to reproduce it, so I'm not gonna open a new issue. Call stack: Component call stack: My id was 397.
The only thing I was doing was hitting right arrow key on this thingy to scroll through my rerenders. !
Ah! (sorry to triple post!) I can reproduce it most of the time by clicking on items in the high thirties for this profile:

} function mountFiberRecursively( <del> fiber: Fiber, </del> <ins> firstChild: Fiber, </ins> parentFiber: Fiber | null, traverseSiblings: boolean, traceNearestHostComponentUpdate: boolean, ) { <del> if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </del> <ins> // Iterate over siblings rather than recursing. // This reduces the chance of stack overflow for wide trees (e.g. lists with many items). let fiber: Fiber | null = firstChild; while (fiber !== null) { if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </ins> <del> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </del> <ins> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </ins> <del> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </del> <ins> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </ins> <del> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; </del> <ins> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; } </ins> } <del> } // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </del> <ins> // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </ins> <del> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } else { let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { mountFiberRecursively( primaryChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } </ins> } } else { <del> let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { </del> <ins> if (fiber.child !== null) { </ins> mountFiberRecursively( <del> primaryChild, </del> <ins> fiber.child, </ins> shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } <del> } else { if (fiber.child !== null) { mountFiberRecursively( fiber.child, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </del> <ins> // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </ins> <del> if (traverseSiblings && fiber.sibling !== null) { mountFiberRecursively( fiber.sibling, parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> fiber = traverseSiblings ? fiber.sibling : null; </ins> } }