jiebi/CodeConvo huggingface dataset:
Change:
var ReactMount = require('ReactMount'); var ReactPerf = require('ReactPerf'); <del> var getTextContentAccessor = require('getTextContentAccessor'); </del> var invariant = require('invariant'); /**

Discussion:
On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )
Change:
} if (styleValue != null) { serialized += processStyleName(styleName) + ':'; <del> serialized += dangerousStyleValue(styleName, styleValue) + ';'; </del> <ins> serialized += dangerousStyleValue(styleName, styleValue, component) + ';'; </ins> } } return serialized || null;

Discussion:
It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.
Change:
nearestMountedAncestor: Fiber | null, error: mixed, ) { <ins> if (__DEV__) { setIsRunningInsertionEffect(false); } </ins> if (sourceFiber.tag === HostRoot) { // Error was thrown at the root. There is no parent, so the root // itself should capture it.

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 ?
Change:
var Constructor = ConvenienceConstructor.type; var proto = Constructor.prototype; <ins> // By handling mixins before any other properties, we ensure the same // chaining order is applied to methods with DEFINE_MANY policy, whether // mixins are listed before or after these methods in the spec. if (spec.hasOwnProperty(MIXINS_KEY)) { RESERVED_SPEC_KEYS.mixins(ConvenienceConstructor, spec.mixins); } </ins> for (var name in spec) { <del> var property = spec[name]; </del> if (!spec.hasOwnProperty(name)) { continue; } <ins> if (name === MIXINS_KEY) { // We have already handled mixins in a special case above continue; } var property = spec[name]; </ins> validateMethodOverride(proto, name); if (RESERVED_SPEC_KEYS.hasOwnProperty(name)) {

Discussion:
Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.
Change:
* Specifies the order in which each transform should run. */ var transformRunOrder = [ <ins> 'reserved-words', </ins> 'es6-arrow-functions', 'es6-object-concise-method', 'es6-object-short-notation',

Discussion:
When I run: The following error is thrown: I'm trying to use a library called in an isomorphic app, which needs server-side rendering. The module works fine client-side, but the JSX/ES6 isn't playing nice on the server even though the server's already set up to render React components and other JSX code. As stated , it seems there's a transformation supported in (via its flag) which isn't supported in . I say "seems" because I have a hard time believing can't do the same thing. What am I missing?
Change:
const nodeRequire = module && module[requireString]; // assuming we're in node, let's try to get node's // version of setImmediate, bypassing fake timers if any. <del> enqueueTaskImpl = nodeRequire('timers').setImmediate; </del> <ins> enqueueTaskImpl = nodeRequire.call(module, 'timers').setImmediate; </ins> } catch (_err) { // we're in a browser // we can't use regular timers because they may still be faked

Discussion:
React version: 16.13.1 This code works fine when using plain , but fails: when is enabled: The warning is caused by an exception happened in this block: This is happening because module brings its own implementation of the object with slightly different behavior which requires context to be properly preserved. This one-line change should do the fix: This issue has also been reported to React-testing-library, which has similar code: Why should this be a fix in React and not in ESM? React relied on undocumented behavior of Node modules loader. It was never guaranteed that it will work without proper context. In fact, it will not work as expected if you try it with any non built-in module The current code in React may break in future if module will be replaced with anything else, or if changes their internal implementation.
Do you want to submit a PR It sounds like a reasonable thing for us to fix.
I could, however I am not sure about testing part. What kind of tests would you expect for this?
Change:
jest.runOnlyPendingTimers(); data = [ <del> await getErrorsAndWarningsForElement(1), await getErrorsAndWarningsForElement(2), </del> <ins> await getErrorsAndWarningsForElementAtIndex(0), await getErrorsAndWarningsForElementAtIndex(1), </ins> ]; expect(data).toMatchInlineSnapshot(` Array [

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:
var ReactTransitionGroup = require('ReactTransitionGroup'); var ReactUpdates = require('ReactUpdates'); <del> var cx = require('cx'); </del> var cloneWithProps = require('cloneWithProps'); var shallowCompare = require('shallowCompare'); var update = require('update');

Discussion:
Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors
Change:
### Getting started <del> For this tutorial, we'll use prebuilt JavaScript files on a CDN. Open up your favorite editor and create a new HTML document: </del> <ins> For this tutorial, we'll use prebuilt JavaScript files on a CDN. Open up `public/index.html` in your favorite editor, which should contain the following: </ins> ```html <!-- index.html -->

Discussion:
Not reporting a bug or issue. I just wanted to let you know I found this part of the walk-through to be unclear and confusing and others may, too: It took me a while to figure out whether I was supposed to be editing in the file provided when I cloned the repo or whether I should make a new file and how to link the two files if they were both necessary. I'm new to React and pretty new to programming overall, but I do have some Javascript and Javascript framework experience. I really enjoyed the walk-through because it was simple to get started, so thanks for the helpful resource!!
Good catch & thanks for the heads up! I'd definitely call that a bug :) We really need to go through the tutorial and make sure it's all cohesive. After 2 years of ad hoc updating it's definitely showing its age. If you have any other feedback (especially as somebody who is relatively new to programming), we'd definitely appreciate it.
No problem! I'm happy to help. Will definitely let you know if I see anything else. Thanks again for the great resources!
I've opened a PR with a minor change to make the bit that mentioned a little easier to follow. +1 on making sure the tutorial is cohesive. What are your thoughts on bringing the actual tutorial as a sub-directory of the React project as opposed to being in a separate repository? I am not even sure myself if that's the best way to go about it, but at least things wouldn't be going out of sync as they are now. If you look at the source code for the tutorial and compare it to the tutorial instructions in the React repo there are some striking differences which might catch people out. The major drawback with this approach would be having to clone the entire React source when you want to get just the tutorial, but I actually don't think that's a bad idea. It might even encourage people to have a poke about the source code, which is always a good thing.
Change:
var instance; var Component = createReactClass({ displayName: 'MyComponent', <ins> mixins: [ { componentWillMount() { this.log('mixin.componentWillMount'); }, componentDidMount() { this.log('mixin.componentDidMount'); }, componentWillUpdate() { this.log('mixin.componentWillUpdate'); }, componentDidUpdate() { this.log('mixin.componentDidUpdate'); }, componentWillUnmount() { this.log('mixin.componentWillUnmount'); }, }, ], </ins> log(name) { ops.push(`${name}: ${this.isMounted()}`); },

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? Calling in in prior versions would return . Now it returns . I believe this was untested behavior before, but the new tests that were may check the wrong value: Changing this line to test for will exhibit the behavior. The fix would be to defer setting the flag to until after all mixins and the method were called on the component. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? and anything using is broken. Working correctly in 15.4.x with .
I fixed this locally by splitting the IsMountedMixin into two: Then installing the Post after the spec has been mixed in: For the life of me I can't find the right repo to PR this against though.
This should be fixed with . Can you please verify?
I don't see that version published yet.
It's not set to (still an RC) but it exists: Will turn into 15.6.0 tomorrow.
Ah indeed. It's probably our internal registry being slow. I'll try it out soon.
Confirmed working correctly in .
Great. Thanks for sending the fix!
Change:
"/.module-cache/" ], "testPathDirs": [ <del> "<rootDir>/src" </del> <ins> "<rootDir>/src", "<rootDir>/eslint-rules" </ins> ], "unmockedModulePathPatterns": [ ""

Discussion:
using npm mocha is not necessarily at (thanks to hoisting). (eg it's actually at for me)
We've found out that it's possible to use eslint-tester with jest, so we should just do that.
Change:
toggleParseHookNames(); }; <ins> const hookParsingFailed = parseHookNames && hookNames === null; let toggleTitle; if (hookParsingFailed) { toggleTitle = 'Hook parsing failed'; } else if (parseHookNames) { toggleTitle = 'Parsing hook names ...'; } else { toggleTitle = 'Parse hook names (may be slow)'; } </ins> const handleCopy = () => copy(serializeHooksForCopy(hooks)); if (hooks === null) {

Discussion:
The named hooks cache returns The first (mixed array of string and null) indicates an overall success, even if some names couldn't be inferred. The second indicates an error (e.g. couldn't locate or load source map). In the event of the 2nd response type, the UI currently does nothing (falls back to default) but we should show an error badge (maybe a disabled but red icon with a tooltip saying there was an error) since it's a confusing user experience to just do nothing.
Change:
expect(summary).toEqual([]); }); <ins> it('should not fail on input change events', function() { var container = document.createElement('div'); var onChange = () => {}; var input = ReactDOM.render( <input checked={true} onChange={onChange} />, container ); expectNoWaste(() => { ReactTestUtils.Simulate.change(input); }); }); </ins> it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => {

Discussion:
Calling results in: (this is on a page internally at Facebook so I assume it's a fairly recent React version)
Are you still experiencing this issue internally? If so, can you create an internal task with details and repro steps? Assign to the oncall, cc the React team. Our internal configuration is a bit different, and we don't want to discuss internal code/details/configurations on github. I'm going to close this out, and we can help you debug using internal tools if you're still running into problems.
Small note for anyone experiencing a similar error message who arrived here by Googling: I got bit by this because I updated and without updating at the same time.
I'm getting this issue after upgrading to react 15.0.1. All my React packages (including perf) is 15.0.1. printExclusive() etc. works, but printWasted gives the exception shown above.
Are you running before using it?
Yes. , and the rest of the Perf API works, for example , but not . I changed over to my 0.14.7 branch, and there everything works like it should, and I double checked that both ReactPerf and React was on 15.0.1. ! I can dig around a bit more if this isn't anything known.
Let’s reopen until we hear more.
I had it working for a few minutes and then it started failing without me doing anything strange.
Thanks for the info, do you also have the same stack trace and error message as the first post?
Yes. I was exposing the object as . I tried again exposing it as and it's working again. Puzzling. I'm using the full 15.0.1 ecosystem, on Babel 6, Webpack and Webpack dev server, testing on Chrome.
Any chance you have a public project where you can more or less consistently reproduce this?
Technically this means there was for which there was no . This code is super fragile so it’s hard to pin it down without having a specific component hierarchy that happens to cause this.
If someone wants to spend some effort tracking it down, I would recommend: just before in . just before in . Then please share the relevant logs that correspond to the ID you see in the message.
Thanks Dan, I'll try setting up that to see if I can help.

Unfortunately I cannot share my project right now because of client terms.
Yeah, I thought this might be the case. Thanks for taking the time to investigate.
OK I the lines and I managed to also reproduce the error. . FYI, my app is a SPA, I captured this on a route where I have a long list of items that can be filtered by certain criteria and doing before filtering and after some of those items were removed because of the filtering.
Thank you, this is very helpful! I’ll dig into it and see if I can repro this given the new info.
Change:
*    React Core     .  General Purpose Event Plugin System */ <ins> var hasEventPageXY; </ins> var alreadyListeningTo = {}; var isMonitoringScrollValue = false; var reactTopListenersCounter = 0;

Discussion:
React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.

No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.
Change:
var initialState = this.getInitialState ? this.getInitialState() : null; if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. <del> if (typeof initialState === 'undefined' && </del> <ins> if (initialState === undefined && </ins> this.getInitialState._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience.

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:
); }); <ins> it('should allow {__html: null}', function() { expect(function() { mountComponent({dangerouslySetInnerHTML: {__html: null} }); }).not.toThrow(); }); </ins> it("should warn about contentEditable and children", function() { spyOn(console, 'error'); mountComponent({contentEditable: true, children: ''});

Discussion:
In following JSX fragment I should guarantee that will never be or : Otherwise throws an error although construction is correct: Should instead of check for ?
Someone else mentioned this being surprising to me too.
I've been experiencing the same issues recently
As far as I understand it, the idea is that is basically the equivalent of a HTML-type. You're not meant to use it as , but as so that you cannot accidentally pass unsafe data. So should be or , in this model it does not make sense to have .
That doesn't mean that people won't write it as – doing so is even pretty reasonable if you're careful about naming your vars/props and do .
The simplest workaround is to coerce into an empty string with . +1 for having React do this internally.
Got surprised by this today, upgrading from to . Was it a "bug" in (i.e. it shouldn't have accepted ), or is it a bug in ? Anyway, will use as suggested by just wanted to point out that it seemed to "work" in .