jiebi/CodeConvo huggingface dataset:
Change:
/** * Hyphenates a camelcased CSS property name, for example: * <del> *   > hyphenate('backgroundColor') </del> <ins> *   > hyphenateStyleName('backgroundColor') </ins> *   < "background-color" <del> *   > hyphenate('MozTransition') </del> <ins> *   > hyphenateStyleName('MozTransition') </ins> *   < "-moz-transition" <del> *   > hyphenate('msTransition') </del> <ins> *   > hyphenateStyleName('msTransition') </ins> *   < "-ms-transition" * * As Modernizr suggests (http://modernizr.com/docs/#prefixed), an `ms` prefix

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:
cloneUpdateQueue(current, workInProgress); <del> const oldProps = workInProgress.memoizedProps; instance.props = </del> <ins> const unresolvedOldProps = workInProgress.memoizedProps; const oldProps = </ins> workInProgress.type === workInProgress.elementType <del> ? oldProps : resolveDefaultProps(workInProgress.type, oldProps); </del> <ins> ? unresolvedOldProps : resolveDefaultProps(workInProgress.type, unresolvedOldProps); instance.props = oldProps; const unresolvedNewProps = workInProgress.pendingProps; </ins> const oldContext = instance.context; const contextType = ctor.contextType;

Discussion:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is
Change:
return ( <FixtureSet title="Mouse Events"> <MouseMovement /> <ins> <MouseEnter /> </ins> </FixtureSet> ); }

Discussion:
Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. 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: What is the expected behavior? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .
Change:
]); grunt.registerTask('build:test', [ 'delete-build-modules', <del> 'test:eslint-rules', </del> 'jsx:test', 'version-check', 'populist:test',

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:
.filter(function(npmTaskName) { return npmTaskName != 'grunt-cli'; }) .forEach(function(npmTaskName) { grunt.loadNpmTasks(npmTaskName); }); <del> // Alias 'jshint' to 'lint' to better match the workflow we know grunt.registerTask('lint', ['jshint']); </del> <ins> // Super simplified eslint task that we can use to replace linting. This just // shells out to eslint. grunt.registerTask('eslint', function() { var done = this.async(); grunt.util.spawn({ cmd: 'node_modules/.bin/eslint', args: ['src'] }, function(err, result, code) { if (result.stdout.length) { grunt.warn(result.stdout); } done(code === 0); }); }); grunt.registerTask('lint', ['eslint']); </ins> grunt.registerTask('download-previous-version', require('./grunt/tasks/download-previous-version.js'));

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:
// TODO: When is this not true? if (ReactComponent.isValidComponent(child)) { this.removeChild(child); <del> child._mountImage = null; </del> child._mountIndex = null; child.unmountComponent(); delete this._renderedChildren[name];

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:
react_docs: { files: [ { <del> src: ['react.min.js', 'JSXTransformer.js'], </del> <ins> src: ['react.js', 'JSXTransformer.js'], </ins> dest: 'docs/js/', cwd: 'build/', expand: true

Discussion:
Sometimes it's helpful for to have a playground for grokking React's features, and I like to use the live editor on the docs site to sketch out ideas and see how my code is called by the library. It'd be a huge help if the site's React source was served unminified so it's more apparent what's going on under the covers.
I think this would be helpful:
I think I'd be okay with this. Want to send a PR?
Change:
}); it("does not bail out if there's a context change", async () => { <del> const {Suspense} = React; </del> const CountContext = React.createContext(0); function readContext(Context) {

Discussion:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). 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: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0
Change:
.center { text-align: center; } <ins> input { font-family: inherit; } </ins>

Discussion:
It doesn't match the rest of our text. I think a in the right place in the stylesheet should fix this. !
Pretty sure this is already correct…
It's not. Proxima Nova on the body vs. the default sans system font (San Francisco in the screenshot) in the
The font is indeed different. With font-family inherited: <img width="248" alt="screen shot 2016-09-13 at 00 27 38" src=""Without (current): <img width="244" alt="screen shot 2016-09-13 at 00 27 48" src=""
touché - I had unchecked the browser-styles box in my inspector at some point and so it showed it inheriting the html style… oops. (the Proxima Nova "R" and SF "R" look similar enough that it fooled me too). We could probably just make in as opposed to targeting just this one - we already have that for headers.
Adjusted the PR to include just that
Closed with
Change:
.Value { color: var(--color-attribute-value); <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> overflow: hidden; text-overflow: ellipsis; cursor: default;

Discussion:
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!
Change:
It's as simple as assigning a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref={ function(component){ React.findDOMNode(component).focus();} } /> ``` </del> <ins> ```html render: function() { return <TextInput ref={(c) => this._input = c} } />; }, componentDidMount: function() { this._input.focus(); }, ``` or ```html render: function() { return ( <TextInput ref={function(input) { if (input != null) { input.focus(); } }} /> ); }, ``` Note that when the referenced component is unmounted and whenever the ref changes, the old ref will be called with `null` as an argument. This prevents memory leaks in the case that the instance is stored, as in the first example. Note that when writing refs with inline function expressions as in the examples here, React sees a different function object each time so on every update, ref will be called with `null` immediately before it's called with the component instance. </ins> ## Completing the Example

Discussion:
I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.
Change:
}); ``` <del> ### function createClass(object specification) </del> <ins> #### React.createClass ```javascript function createClass(object specification) ``` </ins> Creates a component given a specification. A component implements a `render` method which returns a single child. That child may have an arbitrarily deep child structure. One thing that makes components different than a standard prototypal classes is that you don't need to call new on them. They are convenience wrappers that construct backing instances (via new) for you. <del> ### ReactComponent renderComponent(ReactComponent container, DOMElement mountPoint) </del> <ins> #### React.renderComponent ```javascript ReactComponent renderComponent(ReactComponent container, DOMElement mountPoint) ``` </ins> Renders a React component into the DOM in the supplied `container`.

Discussion:
I have a fresh installation of Ubuntu 14.04 and installed compiled version of 10.38. failed on step with error 'make: g++: Command not found'. solves the problem. It make sense put g++ dependency into Prerequisites section.
That's kind of annoying but yea, we might need to do something like that. Compilers are a dependency for any binary npm module (which one of our dependencies depends on). Even contextify itself doesn't call out the need for g**. When you install node / npm via does it not install as well? It seems like it should since that's a requirement for many modules.
I used the recommended approach for . is not a part of installation. But I see your point, contextify setup on Windows even more .
The installation of build-essential is not 'optional'. It is a prerequisite for otherwise node-gyp will fail. The instructions for the Debian-based installation should reflect that build-essential is a prerequisite.
for installing g++ in fedora and other linux os use sudo yum install /usr/bin/g++ or sudo dnf install gcc-c++
fixed it for me (Ubuntu)
works for CentOS7, too. :)
What about Mac?
Change:
place, }); } else if (propertyPath.isObjectMethod()) { <ins> if (propertyPath.node.kind !== "method") { builder.errors.push({ reason: `(BuildHIR::lowerExpression) Handle ${propertyPath.node.kind} functions in ObjectExpression`, severity: ErrorSeverity.Todo, loc: propertyPath.node.loc ?? null, suggestions: null, }); continue; } </ins> const method = lowerObjectMethod(builder, propertyPath); const place = lowerValueToTemporary(builder, method); const loweredKey = lowerObjectPropertyKey(builder, propertyPath);

Discussion:
[ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization) [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin) [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin) [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script) In the above code, doubleValue uses get syntax, and after compilation, it loses the keyword and becomes an ordinary function. In this case the compiler should skip compilation until this syntax is supported. I know that some syntaxes are currently unsupported by the react compiler, can we know what syntaxes are currently unsupported and in process? Every time 0-rc--
Thanks for posting, this is a bug. We have not support for get/set syntax but looks like we missed a todo for this.
Let’s close when the associated PR lands
Oops my bad, I didn't read
Change:
* Creates a child component. * * @param {ReactComponent} child Component to create. <ins> * @param {string} mountImage Markup to insert. </ins> * @protected */ <del> createChild: function(child) { enqueueMarkup(this._rootNodeID, child._mountImage, child._mountIndex); </del> <ins> createChild: function(child, mountImage) { enqueueMarkup(this._rootNodeID, mountImage, child._mountIndex); </ins> }, /**

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:
// Make sure we set .type before any other properties (setting .value // before .type means .value is lost in IE11 and below) type: undefined, <del> }, props, { </del> <ins> }, DisabledInputUtils.getNativeProps(inst, props), { </ins> defaultChecked: undefined, defaultValue: undefined, value: value != null ? value : inst._wrapperState.initialValue,

Discussion:
The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.
Change:
function isPresto() { const opera = window.opera; return ( <ins> opera !== null && </ins> typeof opera === 'object' && typeof opera.version === 'function' && parseInt(opera.version(), 10) <= 12

Discussion:
I want to report a bug. When there is a var named opera with value null in window before loading react then react app crashes. Steps to reproduce: 1) Create a new app using create-react-app my-app 2) cd my-app && yarn start 3) Add one line (</script) just before closing body tag into file 4) The app crashes here. Couldn't reproduce on I think because problem appears if we execute BEFORE loading react. Expected behavior is to not crash. React v16.2.0 and Google Chrome Version 63.0.3239.84 (Official Build) (64-bit). Have no info about problematic behavior with previous versions of React.
Closed by
Change:
} `, }, <ins> { code: normalizeIndent` function App(props) { React.useEffect((() => { console.log(props.test); }) as any, [props.test]); } `, }, </ins> ], invalid: [ {

Discussion:
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.
Change:
<ins> --- id: perf title: Performance Tools layout: docs permalink: perf.html prev: pure-render-mixin.html --- React is usually quite fast out of the box. However, in situations where you need to squeeze every ounce of performance out of your app, it provides a [shouldComponentUpdate](/react/docs/component-specs.html#updating-shouldcomponentupdate) hook where you can add optimization hints to React's diff algorithm. In addition to giving you an overview of your app's overall performance, ReactPerf is a profiling tool that tells you exactly where you need to put these hooks. > Note: > > The dev build of React is slower than the prod build, due to all the extra logic for providing, for example, React's friendly console warnings (stripped away in the prod build). Therefore, the profiler only serves to indicate the _relatively_ expensive parts of your app. ## General API ### `Perf.start()` and `Perf.stop()` Start/stop the measurement. The React operations in-between are recorded for analyses below. Operations that took an insignificant amount of time are ignored. ### `Perf.printInclusive(measurements)` Prints the overall time taken. If no argument's passed, defaults to all the measurements from the last recording. This prints a nicely formatted table in the console, like so: ![](/react/img/docs/perf-inclusive.png) ### `Perf.printExclusive(measurements)` "Exclusive" times don't include the times taken to mount the components: processing props, `getInitialState`, call `componentWillMount` and `componentDidMount`, etc. ![](/react/img/docs/perf-exclusive.png) ### `Perf.printWasted(measurements)` **The most useful part of the profiler**. "Wasted" time is spent on components that didn't actually render anything, e.g. the render stayed the same, so the DOM wasn't touched. ![](/react/img/docs/perf-wasted.png) ### `Perf.printDOM(measurements)` Prints the underlying DOM manipulations, e.g. "set innerHTML" and "remove". ![](/react/img/docs/perf-dom.png) ## Advanced API The above print methods use `Perf.getLastMeasurements()` to pretty-print the result. ### `Perf.getLastMeasurements()` Get the measurements array from the last start-stop session. The array contains objects, each of which looks like this: ```js { // The term "inclusive" and "exclusive" are explained below "exclusive": {}, // '.0.0' is the React ID of the node "inclusive": {".0.0": 0.0670000008540228, ".0": 0.3259999939473346}, "render": {".0": 0.036999990697950125, ".0.0": 0.010000003385357559}, // Number of instances "counts": {".0": 1, ".0.0": 1}, // DOM touches "writes": {}, // Extra debugging info "displayNames": { ".0": {"current": "App", "owner": "<root>"}, ".0.0": {"current": "Box", "owner": "App"} }, "totalTime": 0.48499999684281647 } ``` </ins>

Discussion:
I'll let write these, but it would be nice to get them spot checked by and/or