jiebi/CodeConvo huggingface dataset:
Change:
} var markup = null; if (this._tag != null && isCustomComponent(this._tag, props)) { <del> if (propKey !== CHILDREN) { </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { </ins> markup = DOMPropertyOperations.createMarkupForCustomAttribute(propKey, propValue); } } else if (this._namespaceURI === DOMNamespaces.svg) { <del> markup = DOMPropertyOperations.createMarkupForSVGAttribute(propKey, propValue); </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { markup = DOMPropertyOperations.createMarkupForSVGAttribute(propKey, propValue); } </ins> } else { markup = DOMPropertyOperations.createMarkupForProperty(propKey, propValue); }

Discussion:
See for a basic example. I'm assuming there's some step in the new SVG code that we just need to remove the key if we consume it as a React prop.
Going to leave this open to ensure we block even though wrote fix before I finished submitting (do you ever sleep Dan!?)
I sleep incrementally. FWIW the fix is in
Change:
) { return true; } <ins> if (isCustomComponentTag) { return false; } </ins> if (propertyInfo !== null) { switch (propertyInfo.type) { case BOOLEAN:

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. 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: Sorry, it's a CodePen. This example uses a framework called OnsenUI that internally uses web components. In the OnsenUI framework there is an icon web component that transforms every size prop value into a string which is not attached to the DOM. I know that the example has more dependencies than React, BUT there is also a simple div (as simple as this ) which is also affected by this issue. What is the expected behavior? The size prop should be to the DOM when it is not a number on HTML tags that aren't inputs and selects. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? The affected versions are = 16.3 It works ok in versions <= 16.2 Browsers: All
The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. What are the HTML tags that have a attribute except inputs and selects? With web components I am not seeing the issue: <img width="227" alt="screen shot 2018-04-26 at 7 51 53 pm" src="https://user-"
the attribute is an HTML attribute, not something that React provides. According to the HTML spec, is only allowed on and elements
I don't know why I wrote "rest of HTML tags", my bad . The example you provided works ok, but if I add something that doesn't seems like a valid size then it doesn't work. For example: Value | Works -------|------- 100 | Yes 10px | No 10e1 | Yes -1 | No Something changed in 16.3.

Version 16.3 <img width="853" alt="captura de pantalla 2018-04-26 a las 21 36 43" src="https://user-"Version 16.2 <img width="855" alt="captura de pantalla 2018-04-26 a las 21 37 10" src="https://user-" I suppose that it's fine to filter props when not passing the appropriate values when using HTML tags but I suppose that in web components the size attribute can be anything. Am I wrong? What do you think?
The web component code path shouldn't reject any attributes. If it does it's a bug.
The bug is . Before the we should add something like Please send a PR :-)
Ok, I will work on this tomorrow. I'm heading to bed. Thanks for your quick response.
Couldn't wait
Should be fixed in React 16.4.
Change:
.DevTools, .DevTools * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); }

Discussion:
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-"
Change:
transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; <del> this.createChild(child); </del> <ins> this.createChild(child, mountImage); </ins> this._renderedChildren = this._renderedChildren || {}; this._renderedChildren[name] = child; },

Discussion:
We're currently not cleaning up strings from _mountImage after a component gets mounted. That memory could be freed. But the act of freeing the memory could be more expensive than it's worth. Needs proper benchmarks and a workaround.
I noticed this a little while ago. I'm not sure why we need to store it on the child instance in the first place -- PR incoming.
Change:
var args = [ "bin/jsx", <ins> "--cache-dir", ".module-cache", </ins> config.sourceDir, config.outputDir ];

Discussion:
has two calls to the Component class construction which are missing use of the 'new' operator. The calls are like this: Component(publicProps, publicContext, updateQueue) and are here: and here:
This is intentional. We check if we need to construct , and then use it to either call or not. This lets us support functional components and factory components:
Change:
rootType = fiberRoot._debugRootType; } <del> const errors = fiberToErrorsMap.get(id) || new Map(); const warnings = fiberToWarningsMap.get(id) || new Map(); </del> <ins> const errors = fiberIDToErrorsMap.get(id) || new Map(); const warnings = fiberIDToWarningsMap.get(id) || new Map(); </ins> return { id,

Discussion:
the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4
Change:
matrix: fast_finish: true allow_failures: <del> - env: TEST_TYPE=lint </del> - env: TEST_TYPE=test:coverage - env: TEST_TYPE=perf:full - env: TEST_TYPE=test:webdriver:saucelabs:modern

Discussion:
We're blocked on a few things here. Current JSHint is incompatible with what we do with template strings. I have a PR up there to mostly fix it but I bet there are more things. So even after that I think we'll want to switch to using ESLint. However that has its own set of problems as it is still working on ES6/JSX support (mostly blocked on other libraries at this point it seems). I have a PR () up to start using eslint, but there are a few rules disabled (because of incompatibilities on their end) which are really important and enabling them is a blocker for this. [x] Use eslint () [x] Enable all appropriate rules [ ] Add custom rules (namely, must use string literals for 2nd argument)
Change:
setContentDOMNode, setProjectRoots, setStatusListener, <ins> setDisconnectedCallback, </ins> startServer, openProfiler, };

Discussion:
Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!
Change:
expect(node.value).toBe('0'); }); <ins> it('should have the correct target value', function() { var handled = false; var handler = function(event) { expect(event.target.nodeName).toBe('INPUT'); handled = true; }; var stub = <input type="text" value={0} onChange={handler} />; var container = document.createElement('div'); var node = React.render(stub, container); node.value = 'giraffe'; var fakeNativeEvent = new function() {}; fakeNativeEvent.target = node; fakeNativeEvent.path = [node, container]; ReactTestUtils.simulateNativeEventOnNode( EventConstants.topLevelTypes.topInput, node, fakeNativeEvent ); expect(handled).toBe(true); }); </ins> it('should not set a value for submit buttons unnecessarily', function() { var stub = <input type="submit" />; stub = ReactTestUtils.renderIntoDocument(stub);

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:
import type {SourceConsumer} from './astUtils'; const SOURCE_MAP_REGEX = / ?sourceMappingURL=([^s'"]+)/gm; <del> const ABSOLUTE_URL_REGEX = /^https?:///i; </del> const MAX_SOURCE_LENGTH = 100_000_000; type AST = mixed;

Discussion:
This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).
Change:
<del> reactjs.org </del>  No newline at end of file <ins> react.dev </ins>

Discussion:
React GitHub page () ( branch) currently pointing to and then it redirects to So many redirects, can we update the content of file with , if it ok to do, then I am very happy to do the same and I'll contribution in real open source project.
Thanks for pointing this out
Thanks I thought I would get an opportunity to merge the code :(( Is it good to raise a pull request together when we raise any issue, and we know the fix of that issue?
Change:
warning( false, <del> 'Don't set .props.' + propName + ' of the React component' + elementInfo + '. Instead, specify the correct value when ' + 'initially creating the element.' + ownerInfo </del> <ins> 'Don't set .props.%s of the React component%s. ' + 'Instead, specify the correct value when ' + 'initially creating the element.%s', propName, elementInfo, ownerInfo </ins> ); }

Discussion:
Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks
Change:
printOperations, start, stop, <ins> isRunning, </ins> // Deprecated: printDOM, getMeasurementsSummaryMap,

Discussion:
I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR
Change:
return true; } if (requestedBundleTypes.length > 0) { <del> const isAskingForDifferentType = requestedBundleTypes.every( requestedType => bundleType.indexOf(requestedType) === -1 </del> <ins> const isAskingForDifferentType = requestedBundleTypes.some( requestedType => !bundleType.includes(requestedType) </ins> ); if (isAskingForDifferentType) { return true;

Discussion:
React version: 18.x.x up to latest the React repository. : either: - the output of the function logs within the script. Relevant code: Relevant function: The function, responsible for determining whether to include a bundle in the build output, contains incorrect logic for filtering when multiple bundle types are specified. Specifically, the following line causes the issue: This code uses with to check if all requested bundle types are missing in the current bundle type. However, when multiple types are specified, it should skip a bundle only if none of the requested types are present. Here's an example of the incorrect behavior observed during debugging: In this case, even though the is and doesn't include , is incorrectly evaluated as , leading to the bundle not being skipped. The function should correctly filter bundles based on multiple requested types. In the example above, the expected behavior is that should be for the bundle type, as it does not include the type. In general, the function should return (skip the bundle) only if none of the requested types are included in the current bundle type.

<!-- 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: 18.x.x up to latest Node version: 16.x.x up to latest the React repository. : either: - Link to code example: Relevant code: (line 72) Relevant function: The current behavior: When running the commands or , a is thrown: . This is evident in the provided screenshot. The error originates from the function in . The problem stems from how the value is handled. In these specific commands, is passed as an array (e.g., ), but the code incorrectly wraps it in another array: The function then attempts to apply the method to each element of , expecting them to be strings. However, due to the erroneous wrapping, it encounters an array instead, leading to the TypeError. The expected behavior: The or commands should run without errors. The value should be handled correctly even when passed as an array, and bundle type filtering should work as expected. Additional information: The or commands work without issues because the value is passed as a string or undefined. The function generates and arrays based on the provided names ( or ). These arrays are used for bundle filtering in the function.
Change:
expect(node.value).toBe('foobar'); }); <ins> it('should not render value as an attribute', function() { var stub = <textarea value="giraffe" onChange={emptyFunction} />; stub = renderTextarea(stub); var node = stub.getDOMNode(); expect(node.getAttribute('value')).toBe(null); }); </ins> it('should display `value` of number 0', function() { var stub = <textarea value={0} />; stub = renderTextarea(stub);

Discussion:
creates invalid html markup and appears to be unnecessary for proper functionality of the . Admittedly my test here was very minimal, but removing from the object using rendered valid html and the component still worked properly in the browser and passed all it's tests. Other than perhaps supporting server-side rendering, is there a purpose to rendering into the real dom?
Good catch :+1: The reason is set is because is , i.e, it's treated as a property rather than an attribute at run-time (which is correct). But like you say, it should not generate markup for the attribute (because it's wrong). I'm not 100% sure what the preferred fix is here, add another "directive" ex: ?
I don't think it's invalid markup. just isn't used (unless you use , which we don't do for ). I was surprised that just deleting value would work, but I guess we're applying updates to value of the actual node manually, not relying on render. This seems like a good enough approach to me. We already render the initial value as a text child so we don't use this for server rendering. another directive could make sense if we get scoped properties in there since this is only true for <textareabut not for other inputs. But until then... Want to submit a PR (cc
By invalid I meant the generated markup will not validate via the W3C html validator, throwing the error "Attribute value not allowed on element textarea at this point." Yes, I will submit a PR.
Change:
checkMergeArrayArgs: function(one, two) { invariant( Array.isArray(one) && Array.isArray(two), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge arrays, instead got %s and %s.', one, two </ins> ); },

Discussion:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.
Change:
var CSSProperty = require('CSSProperty'); <ins> var camelizeStyleName = require('camelizeStyleName'); </ins> var dangerousStyleValue = require('dangerousStyleValue'); var hyphenateStyleName = require('hyphenateStyleName'); var memoizeStringOnly = require('memoizeStringOnly'); <ins> var warning = require('warning'); </ins> var processStyleName = memoizeStringOnly(function(styleName) { return hyphenateStyleName(styleName); }); <ins> if (__DEV__) { var warnedStyleNames = {}; var warnHyphenatedStyleName = function(name) { if (warnedStyleNames.hasOwnProperty(name) && warnedStyleNames[name]) { return; } warnedStyleNames[name] = true; warning( false, 'Unsupported style property ' + name + '. Did you mean ' + camelizeStyleName(name) + '?' ); }; } </ins> /** * Operations for dealing with CSS properties. */

Discussion:
We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't
Change:
strictModeBadge = ( <a className={styles.StrictModeNonCompliant} <del> href="https://fb.me/devtools-strict-mode" </del> <ins> href="https://react.dev/reference/react/StrictMode" </ins> rel="noopener noreferrer" target="_blank" title="This component is not running in StrictMode. Click to learn more.">

Discussion:
The Strict mode warning badge points to which points to the strict mode section in instead of . Badge: <img width="273" alt="Screenshot 2023-05-16 at 20 20 59" src=""Code: Every time No response No response No response No response No response No response
Thanks for spotting, anyone interested in opening a PR with updating it to
interested, can i proceed and open a PR ? here is the PR
Sorry mate I did not see your comment before starting
Thanks for your contributions Have to go with , as commented a bit earlier.
Change:
getConfig: function() { return { "debug": false, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": false

Discussion:
I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .
Change:
} } <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(true); } } </ins> safelyCallDestroy(finishedWork, nearestMountedAncestor, destroy); <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(false); } } </ins> if (enableSchedulingProfiler) { if ((flags & HookPassive) !== NoHookEffect) {

Discussion:
Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?