jiebi/CodeConvo huggingface dataset:
Change:
{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> });

Discussion:
<!-- 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.0-rc.1 elements out of components, use them conditionally. if the components are dynamically imported. <!-- 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: --The chunk is imported eagerly, even though the component isn't immediately rendered. ! This doesn't happen in prod mode, or with React 16, or with components that are not -ed eagerly. This affects react-router, as it uses this pattern: AFAICT it doesn't break anything, but it is unexpected/confusing. components that are not rendered should not be dynamically imported.
Shorter test case: This is enough to trigger the dynamic import in dev mode.
Behavior changed between 16.13.1 and the first release after . ! !
This is triggered by in . I think this doesn't really make sense to call but we'd need to see why this change to was made. <img width="398" alt="Screenshot 2020-09-03 at 13 56 14" src="https://user-"<img width="367" alt="Screenshot 2020-09-03 at 13 56 18" src="https://user-"
The suspense protocol is just a function that may throw. That allows for low overhead abstractions to be wrapped. This change was to allow the init function to encapsulate the actual suspense mechanism and that data structure. Unfortunately there’s no way to query the status of something in the suspense protocol without triggering the fetch. Same as you can’t do: Without triggering a fetch. The solution might be to move validation of lazy until it’s rendered instead of in createElement. Also, sigh PropTypes.

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.
Change:
} }); <ins> // Make built source available inside npm package grunt.file.mkdir(dist); distFiles.forEach(function(file) { grunt.file.copy('build/' + file, dist + file); }); </ins> // modify build/react-core/package.json to set version ## var pkg = grunt.file.readJSON(dest + 'package.json'); pkg.version = grunt.config.data.pkg.version;

Discussion:
It's nice to have prebuilt binaries available through the current package managers. Right now there's a prebuilt package for , but it'd be nice to also have them on npm / component / What do you think is the best way to create and maintain these packages? cc/
See also .
cc -- Not a blocker for 0.11, but it would be nice if could be merged.
By "binaries" do you actually mean prebuilt versions of React that you can just include on a web page? React doesn't really have binary components.
Yep, that's what I mean.
I'm using in a project and I would love to be able to include react that way. The last conversation about this ended in
We don't have plans to do this right now.
Change:
DOCUMENT_NODE, DOCUMENT_FRAGMENT_NODE, } from '../shared/HTMLNodeType'; <ins> import dangerousStyleValue from '../shared/dangerousStyleValue'; </ins> import type {DOMContainer} from './ReactDOM';

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? Suspense adds display: none to all top level child elements in IE11. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: Code sandbox can't render in IE11 either, but in this example I would expect to not see IE11 because the div would have display: none on it. What is the expected behavior? To be visible and not have display: none on the children. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I had to revert back to react-loadable to fix this.
Is it IE11 specific or a general bug? There’s a few general bugs we’re tracking right now.
IE specific, it worked on Chrome/Safari, but in IE11 the display: none; was left on all the child components. I was able to go and check that style off in the inspector and see the components were loaded just fine.
If I take your CodeSandbox, add react-app-polyfill/ie9 and edit the to compile for IE11 support: – then download that, build it locally, and deploy to at https://build-, then I get a page that successfully displays "hello world" when opened in IE11. !
Can you confirm if I'm doing anything different from what you tested?
Hmm I was hoping it would be as simple as that. But I guess it is more complicated. I'm using it with the router for lazyloading router components. Here is my file that was working everywhere except for IE.
Oh, I think I found the bug.
I love GitHub issues/prs. I can easily track the problem, what caused it, and how to fix it! I was looking for a fix and had one! Thank you!
any ideas when this fix might make it into a release?
PS: We love the work you do for us all!
Any updates to this?
can be fixed with polyfills. It´s described in this pull request
Thanks everyone for this.

The issue itself has been fixed (I think in 16.7).
I'm noticing this problem with react version Suspense/fallback adds a style and this doesn't get removed on IE 11. Works fine on Chrome though.
Change:
}, "dependencies": { "cross-spawn": "^5.0.1", <del> "electron": "^9.1.0", </del> <ins> "electron": "^11.1.0", </ins> "ip": "^1.1.4", "minimist": "^1.2.3", "react-devtools-core": "4.10.1",

Discussion:
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 .
Change:
*/ function createLinkTypeChecker(linkType) { var shapes = { <del> value: typeof linkType === 'undefined' ? </del> <ins> value: linkType === undefined ? </ins> React.PropTypes.any.isRequired : linkType.isRequired, requestChange: React.PropTypes.func.isRequired,

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
setSelection: function(input, offsets) { var start = offsets.start; var end = offsets.end; <del> if (typeof end === 'undefined') { </del> <ins> if (end === undefined) { </ins> end = start; }

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
box-shadow: 0 2px 4px var(--color-shadow); border-radius: 0.25rem; overflow: auto; <del> width: 400px; </del> <ins> width: 410px; </ins> max-width: 100%; }

Discussion:
Website is actually irrelevant, but required. the devtools the settings button. the layout being broken (causing horizontal scrollbar). Screenshot ! Every time No response No response No response No response No response No response
Can you provide some more information? Browser (and version), operating system (and version), DevTools extension version, etc. I can't reproduce this.
Firefox 89, Windows 10, latest extension. It's really not that far-fetched.
I'm not sure why there's hostility in your responses (both to this issue and ). This is a free software product and I'm trying to help you. Providing basic info like browser and operating system version along with a bug report is generally useful, regardless of how far fetched you think the configuration is :smile:
Not sure if this is confirmed by anyone else, but I can reproduce this on Firefox. I'll paste my device information so you can try that out in order to repro. How it looks: ! Machine: Windows 10 Home Browser: Firefox version 89.0.1 (64-bit) Let me know if you need more details, I'll be more than happy to take this up. Update: It also happens on chrome dev tools when you resize your dev tools to some specific width.
If I enable scroll bars on OS X, I can also reproduce this in Firefox. Should be able to fix it then. (Did not have access to a Windows machine to test with.) Edit 1: It looks like this is caused by the tab bar containing too many tabs now (General, Debugging, Components, Profiler, and "x" button). Should be an easy fix. Edit 2: I think the reason for the difference between Firefox and Chrome is that the (supposedly hidden) buttons used for the Tab bar accessibility isn't 0 width for Firefox.
Sorry mate, but I don't understand the question then. You asked for browser & OS, and I gave that exact answer. That's really, honestly, genuinely, everything needed to a repro. I've seen this on every pc running Windows 10 + Firefox so far, which is why it's not that far-fetched. I don't see how that's hostile. And actually, we're trying help each other, aren't we Also how am I responding hostile in ? I'm suggesting a fix. I'm Dutch, so I'm just being direct, not hostile at all. It's my culture, please respect that
Change:
{ "name": "react-devtools", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "repository": {

Discussion:
development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0
Change:
topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ) { return [ extractCompositionEvent( topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ), extractBeforeInputEvent( topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ), ]; },

Discussion:
I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.
Change:
{ "name": "react-devtools-core", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "main": "./dist/backend.js",

Discussion:
local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.
Change:
<del> 'use strict'; var fs = require('fs'); var grunt = require('grunt'); var src = 'gem-react-source/'; var dest = 'build/gem-react-source/'; var build = dest + 'build/'; var buildFiles = [ 'react.js', 'react.min.js', 'JSXTransformer.js', 'react-with-addons.js', 'react-with-addons.min.js', ]; function buildRelease() { if (grunt.file.exists(dest)) { grunt.file.delete(dest); } // Copy gem-react-source/**/* to build/gem-react-source var mappings = [].concat( grunt.file.expandMapping('**/*', dest, {cwd: src}) ); mappings.forEach(function(mapping) { var mappingSrc = mapping.src[0]; var mappingDest = mapping.dest; if (grunt.file.isDir(mappingSrc)) { grunt.file.mkdir(mappingDest); } else { grunt.file.copy(mappingSrc, mappingDest); } }); // Make built source available inside npm package grunt.file.mkdir(build); buildFiles.forEach(function(file) { grunt.file.copy('build/' + file, build + file); }); } function packRelease() { var done = this.async(); var spawnCmd = { cmd: 'gem', args: ['build', 'react-source.gemspec'], opts: { cwd: dest, }, }; grunt.util.spawn(spawnCmd, function(err, result) { if (err) { grunt.log.error(err); } // Gem packing does weird things to versions so 0.12.0-alpha becomes // 0.12.0.pre.alpha. We need to get the filename printed to stdout. var filename = result.stdout.match(/File: (.*)$/)[1]; var buildSrc = 'build/gem-react-source/' + filename; var buildDest = 'build/react-source.tgz'; fs.rename(buildSrc, buildDest, done); }); } module.exports = { buildRelease: buildRelease, packRelease: packRelease, }; </del>

Discussion:
I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)
Change:
* renders >,<, and & as multiple children with clean client render * renders >,<, and & as multiple children with client render on top of good server markup * throws when rendering a string component with server string render <ins> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup </ins> * throws when rendering an undefined component with server string render <ins> * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup </ins> * throws when rendering a number component with server string render <ins> * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </ins> * throws when rendering null with server string render * throws when rendering null with clean client render * throws when rendering null with client render on top of bad server markup

Discussion:
I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.
Change:
): void { for (let i = 0; i < hooksTree.length; i++) { const hook = hooksTree[i]; <ins> if (isUnnamedBuiltInHook(hook)) { // No need to load source code or do any parsing for unnamed hooks. if (__DEBUG__) { console.log('flattenHooksList() Skipping unnamed hook', hook); } continue; } </ins> hooksList.push(hook); if (hook.subHooks.length > 0) { flattenHooksList(hook.subHooks, hooksList);

Discussion:
Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.