jiebi/CodeConvo huggingface dataset:
Code change:
} effect = effect.nextEffect; } while (effect !== null); <ins> if (__DEV__) { resetCurrentFiber(); } </ins> isRendering = previousIsRendering;

Related discussion:
text: I've noticed a strange bug with the react redux opt-in. If i use it with a connected class component, everything is ok: If i use it with a connected functional component that use with , i obtain a strange error: in method. I create a codepen to reproduce the issue: PS: Sorry for the cors error, but i don't find the way to add as cdn
I believe the issue here is that expects the second argument to be a function that returns the reference: See: for more information about the API of the hook. Maybe the error thrown could be more clear?
You're right, accept a function as second argument. A warning on wrong argument type could be a good idea.
Ill take this issue on
Sure
i get TypeError: React.useImperativeMethods is not a function in 16.8.0-alpha.1 but when back to 16.7.0-alpha.2 not get this error
The hook was renamed in this PR: Most likely between the 16.7 alpha and 16.8 alpha
Yeah, it was renamed.
yes it work good after rename it where i can get changes between alpha version ?
Commit log. We don't write changelogs for alphas.
I'm taking this in since we want to get Hooks out sooner.
alright np
Code change:
"node": ">=0.10.0" }, "peerDependencies": { <del> "envify": "~1.0.1" </del> <ins> "envify": "~1.2.0" </ins> }, "browserify": { "transform": ["envify"]

Related discussion:
text: React 0.8 React 0.9 I think this is because of switched to in 1.0.0. I submitted a to envify which uses instead of recast. This brings us back to 1.5s and delivers the same advantages as recast version (preserves code formatting): I think this is blocker for 0.9.0.
What command are you running, and in what directory? I'm having trouble reproducing the slow-down with just .
Code change:
form: MUST_USE_ATTRIBUTE, formNoValidate: HAS_BOOLEAN_VALUE, frameBorder: MUST_USE_ATTRIBUTE, <ins> headers: null, </ins> height: MUST_USE_ATTRIBUTE, hidden: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, href: null,

Related discussion:
text: I am working on a project that has strict accessibility requirements. The table I am putting some data in has to implement headers and ids attributes to meet accessibility. See W3 techniques here Unfortunately the "headers" attribute is being stripped out because it's not supported by React (it's not on the supported attributes list). Can you please add support for the missing standard attribute called "headers"?
+1
As a workaround I believe on a you can grab the DOMNode with a ref and add what you need.
Code change:
override: - ./scripts/circleci/test_entry_point.sh: parallel: true <del> deployment: staging: branch: /.*/ commands: - ./scripts/circleci/upload_build.sh </del>

Related discussion:
text: It looks like this: It happened two times on random commits, and I don't see a pattern. Probably caused by me changing how tasks are distributed between parallel nodes in I don't understand why would try to run before a build exists though (if that's what's happening?)
I think this one would require some experience with CircleCI. I don't have any pointers as to where to start: I don't understand why it's failing myself. So it's not a very beginner-friendly issue (I marked the difficulty as medium for that reason).
Another example:
I want to work on this. After doing some research on circleci document, I didn't find the document said about parallel test and deployment sequence. I'm curious about how circleci deal with parallel test and deployment sequence. I think there are two situations: all parallel test finishes, run deployment sequence. If this is true, I think it won't cause current test error. container runs deployment after the container's test finished. I guess it is more likely in this case. Sometimes it passed, it's because node 2 already built file. Sometimes it failed because node 2 didn't build file yet. So I think maybe that's because each container will run deployment after that node test finished. If the situation is as above, I come up with two solutions. we want to keep current test flow, we can try to keep each node builds time balance. this test at first, then run other test parallel. reference link:
Only node 2 does a full build. So I don't understand how deployment on other nodes could work at all.
Or do nodes share the file system?
I think nodes share the file system. Otherwise, it should fail every time. It will be easier to debug if we can add more log, like current build time and .
Would it make sense to change the upload script to only run on the second node?
Yep, I think so, because in the document I can't ensure whether deployment stage is triggered after all parallel test finished.
Can we just put the deployment command right into the test command? Is there any benefit to separating them?
I think it's also workable, but may lead misunderstanding. Cause we put build process to test stage. Or we can try to use stage. Run at compile stage, so we can promise and stages have needed file.
Code change:
override: - ./scripts/circleci/test_entry_point.sh: parallel: true <del> deployment: staging: branch: /.*/ commands: - ./scripts/circleci/upload_build.sh </del>

Related discussion:
text: The interesting part is our regular tests don't need compilation. If "compile" stage has to run before any other stages then we'll wait unnecessarily. I'd prefer to have a single script that does everything than to buy into CircleCI specific terminology unless it buys us something real good (e.g. parallelism was very useful). Maybe can try this:
OK, I understand your consideration. I think this fix will work. Just tell me if anything can help.
Code change:
workInProgress: Fiber, priorityLevel: PriorityLevel, ): void { <ins> if (__DEV__) { checkClassInstance(workInProgress); } </ins> const instance = workInProgress.stateNode; const state = instance.state || null;

Related discussion:
text: Follow up from Here's one I found. These two invariants: are in a function that's behind a DEV block: I don't think this is intentional, but need to verify. There may be more. I'll use this issue to track while preserves existing behavior.
Here’s another difference: in development, putting a string ref on a functional component throws with: Stateless function components cannot have refs. but in production gives you: Element ref was specified as a string but no owner was set.
Code change:
<ins> --- layout: none --- <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>{{ site.name }}</title> <description>{{ site.description }}</description> <link>{{ site.url }}{{ site.baseurl }}</link> <atom:link href="{{ site.url }}{{ site.baseurl }}/feed.xml" rel="self" type="application/rss+xml" /> {% for post in site.posts limit:10 %} <item> <title>{{ post.title | xml_escape }}</title> <description>{{ post.content | xml_escape }}</description> <pubDate>{{ post.date | date_to_xmlschema }}</pubDate> <link>{{ site.url }}{{ site.baseurl }}{{ post.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ site.baseurl }}{{ post.url }}</guid> </item> {% endfor %} </channel> </rss> </ins>

Related discussion:
text: As it is known (but ), React's SyntheticEvent is pooled. This is confusing for many users as they don't understand why the event starts to behave strangely when used in an async callback, like inside a , a or a callback. There has already been an attempt to solve this problem here: The code of SyntheticEvent's default methods is: It may make sense to be more defensive because calling on a pooled event will raise . It would be more useful to add a check like:
To illustrate the problem in not being defensive, I would give you this commit that has made it into production as a workaround in React-tappable: Basically the user is trying to assign an empty function to a SyntheticEvent that as been put back in the pool (the call to persist was from another PR at the same time). And we were basically 3 concurrent PR to try different solutions to the exact same problem.
As the person who made the PR in a panic, I did find the code that broke in react itself. the preventDefault method tries to call the method on . A simple if check for in the method, and a no-op if null would be a great fix to this problem. Similar to how setState is handled on an unmounted component.
I think React should not swallow this error and be fail fast, because this does not make any sense to preventDefault in an async callback (because the default already has been applied), React should rather throw an error. But this is only my opinion, because the browser behavior with dom events is not fail fast and swallow that bad usage of preventDefault. I mean the browser does not throw an error when we do: It simply has no effect (like what you suggest) I don't like this and would rather change the behavior of both React and the browser, but I don't think I can do much on my own... Maybe at least React could issue a warning in DEV env?
Yeah, I think warning is appropriate here.
A warning would be great!
Just wonder what kind of message should be put into this warning. If event pooling is not going to be documented (will it?), it may be strange to explain the pooling system inside a warning no?
Yes, event pooling should/will be documented. Feel free to submit a PR. We should add a warning to let the user know that the event has been returned to the pool and so invoking methods on it makes no sense.
Code change:
<ins> --- layout: none --- <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>{{ site.name }}</title> <description>{{ site.description }}</description> <link>{{ site.url }}{{ site.baseurl }}</link> <atom:link href="{{ site.url }}{{ site.baseurl }}/feed.xml" rel="self" type="application/rss+xml" /> {% for post in site.posts limit:10 %} <item> <title>{{ post.title | xml_escape }}</title> <description>{{ post.content | xml_escape }}</description> <pubDate>{{ post.date | date_to_xmlschema }}</pubDate> <link>{{ site.url }}{{ site.baseurl }}{{ post.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ site.baseurl }}{{ post.url }}</guid> </item> {% endfor %} </channel> </rss> </ins>

Related discussion:
text: Once the docs are written, we can add a link to the end of the warning.
Got a PR for this! Would really appreciate some feedback.
Code change:
export function createCache(invalidator: () => mixed): Cache { const resourceMap: ResourceMap = new Map(); <del> function accessRecord<K, V>(resourceType: any, key: K): Record<V> { </del> <ins> function accessRecord<K, V>(resourceType: any, key: K): Record<K, V> { </ins> if (__DEV__) { warning( typeof resourceType !== 'string' && typeof resourceType !== 'number',

Related discussion:
text: In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.
Code change:
* @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ <ins> 'use strict'; var warning = require('warning'); var warned = false; </ins> function cx(classNames) { <ins> if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } </ins> if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className];

Related discussion:
text: This has no dependencies so I think we should either publish it as a standalone module or direct people to something else from the community. I'm inclined to do the latter since it means we can wash our hands of it. Our internal usage of is tied to our transforms so we've said no to features that would be useful to others outside FB. I'm concerned we'd do that again. Any suggestions for existing projects that we can point to?
Can't we just link to a bunch of "useful scripts" in the docs and leave it at that? People are free to use/modify them, it's implied they're not being maintained and are there just for getting people started. I feel like a lot of people don't understand the current state of , but expect them to be full-blown frameworks and updated with every feature conceivable. Publishing on NPM kind of continues that trend and I suspect no-one on Team React really cares about the addons enough. So I would say, make them available in the docs (as code/files) and let the community sort out publishing/improving/direction.
...Can I "steal" the code and post it somewhere else under my name? I do need it for another CSS repo of mine, and it's really not React-specific.
After talking with Jed at the conference, I think I'll just point people at
Pete hunt already has react-classset module on npm I believe as well
According to the react-classset has been deprecated in favor of the above mentioned library.
It is. They're pretty much the same except for some negligible differences so I deprecated the former (the latter has an active maintainer).
Code change:
); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { var instance = ( <div> {5} {12} {13} </div> ); var traverseFn = jasmine.createSpy(); traverseAllChildren(instance.props.children, traverseFn, null); expect(traverseFn.calls.length).toBe(3); expect(traverseFn).toHaveBeenCalledWith( null, 5, '.0' ); expect(traverseFn).toHaveBeenCalledWith( null, 12, '.1' ); expect(traverseFn).toHaveBeenCalledWith( null, 13, '.2' ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });

Related discussion:
text: Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"
Code change:
<ins> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; var React; var ReactDOM; var ReactTestUtils; describe('ReactEventIndependence', function() { beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('does not crash with other react inside', function() { var clicks = 0; var div = ReactTestUtils.renderIntoDocument( <div onClick={() => clicks++} dangerouslySetInnerHTML={{ __html: '<button data-reactid=".z">click me</div>', }} /> ); ReactTestUtils.SimulateNative.click(div.firstChild); expect(clicks).toBe(1); }); it('does not crash with other react outside', function() { var clicks = 0; var outer = document.createElement('div'); outer.setAttribute('data-reactid', '.z'); var inner = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, outer ); ReactTestUtils.SimulateNative.click(inner); expect(clicks).toBe(1); }); it('does not when event fired on unmounted tree', function() { var clicks = 0; var container = document.createElement('div'); var button = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, container ); // Now we unmount the component, as if caused by a non-React event handler // for the same click we're about to simulate, like closing a layer: ReactDOM.unmountComponentAtNode(container); ReactTestUtils.SimulateNative.click(button); // Since the tree is unmounted, we don't dispatch the click event. expect(clicks).toBe(0); }); }); </ins>

Related discussion:
text: Since upgrading from beta3 to rc1 I've seen this error a few times in production. Haven't been able to trace the source yet though. cc
I was unmounting a root during a keyboard event which caused this to happen. I think this has always been a problem? Perhaps we've only been lucky... leaving open just to be sure. EDIT: Could it make sense to have something along the lines of ? Allowing you to schedule things to occur as soon as the current transaction ends.
This invariant was new in this release. We also hit one case at FB that I haven't yet investigated. Probably need to change something for the final release.
I have seen this on RC1 can't find a sequence of actions to repeat it.
I'm running into this issue as well when conditionally rendering based on state. Not sure how to boil it down to a simple reproducible bug report yet.
My issue only happens when I am leveraging FastClick. Didn't happen before 0.14.
I've found it is because the events are handled in a different order with fastclick, so the batching gets weird...
e.g. click gets fired before touchEnd, so click handler setState to remove subtree, and then react tries to do something with it in touch end perhaps?
Code change:
<ins> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; var React; var ReactDOM; var ReactTestUtils; describe('ReactEventIndependence', function() { beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('does not crash with other react inside', function() { var clicks = 0; var div = ReactTestUtils.renderIntoDocument( <div onClick={() => clicks++} dangerouslySetInnerHTML={{ __html: '<button data-reactid=".z">click me</div>', }} /> ); ReactTestUtils.SimulateNative.click(div.firstChild); expect(clicks).toBe(1); }); it('does not crash with other react outside', function() { var clicks = 0; var outer = document.createElement('div'); outer.setAttribute('data-reactid', '.z'); var inner = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, outer ); ReactTestUtils.SimulateNative.click(inner); expect(clicks).toBe(1); }); it('does not when event fired on unmounted tree', function() { var clicks = 0; var container = document.createElement('div'); var button = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, container ); // Now we unmount the component, as if caused by a non-React event handler // for the same click we're about to simulate, like closing a layer: ReactDOM.unmountComponentAtNode(container); ReactTestUtils.SimulateNative.click(button); // Since the tree is unmounted, we don't dispatch the click event. expect(clicks).toBe(0); }); }); </ins>

Related discussion:
text: It sounds like this bug is likely to trigger when you use a non-React component (e.g. jQuery UI) in a React single page application and the non-React component triggers a navigation within the app.
Thanks for an excellent bug report and good repro case! I think this happens because we use the "root id" to determine which element was clicked. In the repro case there is no "key" as part of the root ID for two reasons: 1) It is not a child of a container (multichild) so it doesn't get a key to the root ID. 2) It doesn't have a unique key and doesn't need one because it the button is of a different type. If I make sure that a key is used as part of the root ID the problem is solved: So the problem in the repro isn't that we're firing on a removed node, it is that we're firing the event on the new node. This would be solved if we used a unique ID per instance to identify event handlers instead of a generate root that is non-unique. Which I think we wanted to do anyway. Is there another repro that shows a different issue?
Code change:
describe('ReactDOMComponent', function() { var React; var ReactDOM; <del> var ReactDOMFeatureFlags; </del> var ReactDOMServer; beforeEach(function() { jest.resetModuleRegistry(); React = require('React'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags') </del> ReactDOM = require('ReactDOM'); ReactDOMServer = require('ReactDOMServer'); });

Related discussion:
text: Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!
Code change:
- Gemfile.lock - README.md - Rakefile <ins> url: http://facebook.github.io </ins> baseurl: /react permalink: /blog/:year/:month/:day/:title.html

Related discussion:
text: As it is known (but ), React's SyntheticEvent is pooled. This is confusing for many users as they don't understand why the event starts to behave strangely when used in an async callback, like inside a , a or a callback. There has already been an attempt to solve this problem here: The code of SyntheticEvent's default methods is: It may make sense to be more defensive because calling on a pooled event will raise . It would be more useful to add a check like:
To illustrate the problem in not being defensive, I would give you this commit that has made it into production as a workaround in React-tappable: Basically the user is trying to assign an empty function to a SyntheticEvent that as been put back in the pool (the call to persist was from another PR at the same time). And we were basically 3 concurrent PR to try different solutions to the exact same problem.
As the person who made the PR in a panic, I did find the code that broke in react itself. the preventDefault method tries to call the method on . A simple if check for in the method, and a no-op if null would be a great fix to this problem. Similar to how setState is handled on an unmounted component.
I think React should not swallow this error and be fail fast, because this does not make any sense to preventDefault in an async callback (because the default already has been applied), React should rather throw an error. But this is only my opinion, because the browser behavior with dom events is not fail fast and swallow that bad usage of preventDefault. I mean the browser does not throw an error when we do: It simply has no effect (like what you suggest) I don't like this and would rather change the behavior of both React and the browser, but I don't think I can do much on my own... Maybe at least React could issue a warning in DEV env?
Yeah, I think warning is appropriate here.
A warning would be great!
Just wonder what kind of message should be put into this warning. If event pooling is not going to be documented (will it?), it may be strange to explain the pooling system inside a warning no?
Yes, event pooling should/will be documented. Feel free to submit a PR. We should add a warning to let the user know that the event has been returned to the pool and so invoking methods on it makes no sense.