jiebi/CodeConvo huggingface dataset:
Code change:
/** * @private */ <ins> _renderValidatedComponentWithoutOwnerOrContext: function() { var inst = this._instance; var renderedComponent = inst.render(); if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. if (typeof renderedComponent === 'undefined' && inst.render._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience. renderedComponent = null; } } return renderedComponent; }, /** * @private */ </ins> _renderValidatedComponent: ReactPerf.measure( 'ReactCompositeComponent', '_renderValidatedComponent',

Related discussion:
text: Therefore, I think the default should be to filter out nulls which is consistent with the behavior of the built-ins components. It is still possible to get access to the raw data if you have a different type of children in mind where empty slots is meaningful.
How should this work with the TestUtils functions. For example, this fails: I can't see any other info on mentioned at the start of this issue, is this what I'm missing? My end goal is simply to test that if I pass in 10 articles then 10 components get rendered. Any help would be awesome.
Hi David, the and functions are meant to be used with the output of , not shallow rendering. React doesn't currently provide a helper that will traverse trees for you. Your options for now are to describe the structure of the tree explicitly as in lines 4-5 of your example, or write your own helper module to find descendants you care about. hasn't been implemented yet. Refer to the for what's actually in React.
Cool, thanks for the reply I've returned to just using since the components I'm testing (and their children) don't have state/stores so don't really need mocking out anyway. One last (maybe stupid) question, what does mean?
So, I am trying to use Shallow Rendering and have it mostly only thing left I can’t figure out is the recommended way to mock events and how to get with events to pass. I've attempted to use the method directly from the in the test (). This seems dirty…is there a way to just say or something? I could post this on Stack Overflow, but I have had very little luck finding good information about Shallow Rendering online. If anyone has experience with shallow rendering and can give me some help you will be my hero... Source code: ! !
If I have an issue with shallow rendering, should I create a new issue, or post it here?
New issue please.
you might find that helps in providing higher-level assertions for the sort of thing you're doing there. In that particular case, I would avoid asserting on the event handler of the anchor in that test - but a different test would want to call to test the handler.
Super late reply, but "scry" is a fancy word for "find". I'm not sure why we don't just use "find".
Code change:
/** * @private */ <ins> _renderValidatedComponentWithoutOwnerOrContext: function() { var inst = this._instance; var renderedComponent = inst.render(); if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. if (typeof renderedComponent === 'undefined' && inst.render._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience. renderedComponent = null; } } return renderedComponent; }, /** * @private */ </ins> _renderValidatedComponent: ReactPerf.measure( 'ReactCompositeComponent', '_renderValidatedComponent',

Related discussion:
text: Maybe to avoid confusion between the plural and singular forms, whose names would otherwise differ only by one "s".
scry is because of legacy internal FB APIs. No reason.
Like I'm keenly on the lookout for a way to correctly unit test event handling in React code. Is there any documentation that anyone could point me to? I've looked at but it didn't seem to have something that scratches my particular itch. Here's my scenario (cut down): Where Problem looks like this: I'd like to be able to assert that is wired up for my component but I'm at a loss as to how to do that....
What you actually want is to assert that clicking interacts with the router. Pass in a fake context with a router mock (try Simon) then call Apologies for the brevity, on a phone.
Hi Thanks for responding. I'm not too clear on how to mock successfully when it comes to context. Digging through the source of I came up with this: However this dies a death with: Which makes me think I'm getting the context mocking wrong. Do you know how you successfully mock context with ? I'm using Jasmine (as you probably guessed!) I have a feeling I'm close...
Are you using React 0.13? You're probably hitting the difference between parent & owner context. Skin deep has a wrapper that helps with this - there's a context example the test suite, but the short answer is to wrap your render in another function call and let skin deep set up the context. This problem should go away in 0.14
I am using React 0.13, yes. If I port to 0.14 this issue should resolve? I might give that a crack if that's the case (it is in RC after all)
Problems with the upgrade. I have raised . Will have to return to this later I think.
I have written and as companion tools when testing with shallow rendering. It gives you the ability to diff on JSX strings rendered instead of React element objects.
Hi, I was wondering what was the state of: simulating events when using shallow rendering using refs when using shallow rendering How can we help make this happen if that's still planned?
This issue is pretty stale so I’ll close it.
Code change:
/** * @private */ <ins> _renderValidatedComponentWithoutOwnerOrContext: function() { var inst = this._instance; var renderedComponent = inst.render(); if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. if (typeof renderedComponent === 'undefined' && inst.render._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience. renderedComponent = null; } } return renderedComponent; }, /** * @private */ </ins> _renderValidatedComponent: ReactPerf.measure( 'ReactCompositeComponent', '_renderValidatedComponent',

Related discussion:
text: If there are specific features you miss in the shallow renderer please create new issues with proposals on how they should work. Note that we a new that is much more feature-complete.
Code change:
httpEquiv: null, icon: null, id: MUST_USE_PROPERTY, <ins> keyParams: MUST_USE_ATTRIBUTE, keyType: MUST_USE_ATTRIBUTE, </ins> label: null, lang: null, list: MUST_USE_ATTRIBUTE,

Related discussion:
text: I'm using tag to generate client certificates and I'm missing challenge and keytype attributes.
It would be cool if React gives us the opportunity to use different syntax for attrs and props: And may be: There would be no need to know what tags React supporting.
There's more planned to alleviate the issues around unknown elements and properties, but we're not there yet. We have no plans on to use different syntax. Adding the additional attributes here seems totally reasonable.
Will try to take a stab at this. I assume this is as simple as adding those props to , and then adding tests. Is that correct or am I missing anything significant?
It's even easier than that since we don't really have tests for the attributes. But do actually test in a couple browsers that changing values across renders is reflected appropriately (usually the issues is property vs attribute).
You're quick, guys. Thanks in advance!
By 'across renders' you mean simply triggering a re-render (by changing the value)?
Yea. I usually just make a simple component with a button that toggles state so I can test with multiple values easily.
Great. Thx.
I missed a detail in docs. Although, I don't need it, there's an additional attribute, keyparams, which is required with "dsa" and "ec" keytypes. See
Have this working, though I'm not entirely clear if these should be , or . I wasn't able to deduce the meaning of these from the code. Is there someplace I can read up on these?
Those are used to determine if we do or if we do when updating. means it doesn't matter and browsers should work with either. Currently we use properties in that case but we may switch that in the future. indicate that they must be set & removed as a property or an attribute.
Thanks. That makes sense. Had to use to get it to work properly across Chrome/FF/Safari. Your testing method great as well. Thx for your help
Code change:
findHostInstancesForRefresh, } from './ReactFiberHotReloading.old'; import {markRenderScheduled} from './SchedulingProfiler'; <ins> import ReactVersion from 'shared/ReactVersion'; </ins> export {registerMutableSourceForHydration} from './ReactMutableSource.old'; export {createPortal} from './ReactPortal'; export {

Related discussion:
text: This is a followup issue for pmndrs/react-three-fiber From my understanding of , the DevTools parse the version number advertised by the renderer in to select how to parse the internal fiber object. Unfortunately this means that third-party renderers that advertise a version lower than the equivalent React version for the release they are using get misclassified: for instance is using which is equivalent to , and since major version is much lower than it uses the default values for the enum which in turns lead to getting identified as and hook inspection being unavailable. A short term solution for renderers is to advertise a React-compatible version number, but ideally this is an implementation detail of the devtools that users of should not have to be aware of (also this means the version number displayed in the devtools is wrong). I'm not sure I'm familiar enough with the internals of the devtools to open a PR for this, but since the version parsing logic is used to detect features that are internal to anyway I guess a solution would be to have the Reconciler package add its own value for the constant along with the parameters sent to the devtools backend, and have the devtools use this string if its available over the renderer version.
Once and land (and get released) newer versions of the reconciler will inject its own version (to be used instead of the renderer version). Unfortunately this won't help you until you upgrade.
Code change:
}; }, <ins> createRenderer: function() { return new ReactShallowRenderer(); }, </ins> Simulate: null, SimulateNative: {} }; /** <ins> * @class ReactShallowRenderer */ var ReactShallowRenderer = function() { this._instance = null; }; ReactShallowRenderer.prototype.getRenderOutput = function() { return (this._instance && this._instance._renderedComponent) || null; }; var ShallowComponentWrapper = function(inst) { this._instance = inst; } assign( ShallowComponentWrapper.prototype, ReactCompositeComponent.ShallowMixin ); ReactShallowRenderer.prototype.render = function(element) { var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); this._render(element, transaction); ReactUpdates.ReactReconcileTransaction.release(transaction); }; ReactShallowRenderer.prototype._render = function(element, transaction) { if (!this._instance) { var rootID = ReactInstanceHandles.createReactRootID(); var instance = new ShallowComponentWrapper(new element.type(element.props)); instance.construct(element); instance.mountComponent(rootID, transaction, 0); this._instance = instance; } else { this._instance.receiveComponent(element, transaction); } }; /** </ins> * Exports: * * - `ReactTestUtils.Simulate.click(Element/ReactDOMComponent)`

Related discussion:
text: If there are specific features you miss in the shallow renderer please create new issues with proposals on how they should work. Note that we a new that is much more feature-complete.
Code change:
if (consoleSettingsRef.appendComponentStack) { const lastArg = args.length > 0 ? args[args.length - 1] : null; const alreadyHasComponentStack = <del> lastArg !== null && isStringComponentStack(lastArg); </del> <ins> typeof lastArg === 'string' && isStringComponentStack(lastArg); </ins> // If we are ever called with a string that already has a component stack, // e.g. a React error/warning, don't append a second stack.

Related discussion:
text: <!-- 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: DevTools version 4.12.2- from within a React component where the last argument is typeof <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: The bug only happens when you make a change, so if you use the code sandbox link you need, open a new window, active dev tools, open the React dev tools and then uncomment line 5: only then will the error actually happen. I've located the culprit to this line of code And would offer the following change <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --React DevTools is implicitly converting a Symbol to a string. React DevTools does not implicitly try to convert a Symbol to a string.
Thanks for the report. Also reproduced with DevTools version 4.12.3- in Chrome 90 In addition to fixing the bug, it would also be nice to guard against devtools failing so that the UI is unaffected if devtools is faulty. /cc
Your the best, thanks for a quick turn around!
Code change:
"scriptPreprocessor": "scripts/jest/preprocessor.js", "setupEnvScriptFile": "scripts/jest/environment.js", "setupTestFrameworkScriptFile": "scripts/jest/test-framework-setup.js", <ins> "testRunner": "jasmine1", </ins> "testFileExtensions": [ "coffee", "js",

Related discussion:
text: Looks like is broken on a fresh checkout. Just doing a and locally results in running jasmine1, but running the same commands on a fresh checkout attempts to run jasmine2 and results in 300+ failing unit tests.
Code change:
<div class="jsxCompiler"> <h1>HTML to JSX Compiler</h1> <div id="jsxCompiler"></div> <del> <script src="http://reactjs.github.io/react-magic/htmltojsx.min.js"></script> </del> <ins> <script src="https://reactjs.github.io/react-magic/htmltojsx.min.js"></script> </ins> <script src="js/html-jsx.js"></script> </div>

Related discussion:
text: ! Edits were made last week to this page, maybe it was broken accidentally?
I guess you use https, but the page loads a script over http and that gets blocked. I made a pull request to fix this . I couldn't test it, so fingers crossed that it is right.
I though we were going to remove this page and let this live entirely in the react-magic repo?
The scripts live in the react-magic repo, but I think we'll keep the page on the React site as it's still really useful there.
Code change:
}); describe('act', () => { <del> it('works', () => { </del> <ins> it('can use .act() to batch updates and effects', () => { </ins> function App(props) { React.useEffect(() => { props.callback();

Related discussion:
text: <!-- 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. Behavior regression. What is the current behavior? Package throws when being required in Node. 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? should not throw in "pure" node (without providing fake document on global). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? happens on 16.8.0 previous versions work.
We also got this issue after upgrading to 16.8.0
Found the fix and putting together a PR now edit: now on the case
Code change:
<hr class="home-divider" /> <section class="home-bottom-section"> <div class="buttons-unit"> <del> <a href="/getting-started.html" class="button">Get Started</a> <a href="/download.html" class="button">Download React v{{site.react_version}}</a> </del> <ins> <a href="docs/getting-started.html" class="button">Get Started</a> <a href="downloads.html" class="button">Download React v{{site.react_version}}</a> </ins> </div> </section>

Related discussion:
text: <!-- 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: 16.x <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: Nothing. It's part of WAI-ARIA 1.3
I guess the question is what React considers a "valid" aria prop: specific version (range) of Aria version with a (WR,CR,PR,REC) spec editors consider the aria prop that ever existed
Yeah, it seems they've support for this fairly recently.
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” React isn’t the source of truth for that information. It sounds like the job of a linter rather than something react should warn about.
I think it might be from a compiler.
It's from here:
We might also ask: “Why is react telling me what is and isn’t a valid aria attribute.” The reason is that they're often misspelled so on the whole it's beneficial to warn for unknown ones. I'll merge the PR.
Fixed by Will appear in 18.
Code change:
<hr class="home-divider" /> <section class="home-bottom-section"> <div class="buttons-unit"> <del> <a href="/getting-started.html" class="button">Get Started</a> <a href="/download.html" class="button">Download React v{{site.react_version}}</a> </del> <ins> <a href="docs/getting-started.html" class="button">Get Started</a> <a href="downloads.html" class="button">Download React v{{site.react_version}}</a> </ins> </div> </section>

Related discussion:
text: Not sure if this is intentional, but if I run this: The resulting inner div has its set to . the resulting DOM string is: but if I remove the key the result is: If is used as the key, the result is the latter above.
This is intentional. is an intentional value whereas is the lack of a specified value.
If that's the case then IMHO we should escape it properly, as it is now and are treated equally by React (this should be trivial by translating it to or whatever. Although personally I'm not sure when it ever makes sense to have as a key, how about a warning too?
Code change:
}); }); <ins> it('should call componentWillUnmount before unmounting', function() { var container = document.createElement('div'); var innerUnmounted = false; spyOn(ReactMount, 'purgeID').andCallThrough(); var Component = React.createClass({ render: function() { return <div> <Inner /> </div>; } }); var Inner = React.createClass({ componentWillUnmount: function() { // It's important that ReactMount.purgeID be called after any component // lifecycle methods, because a componentWillMount implementation is // likely call this.getDOMNode(), which will repopulate the node cache // after it's been cleared, causing a memory leak. expect(ReactMount.purgeID.callCount).toBe(0); innerUnmounted = true; }, render: function() { return <div />; } }); React.renderComponent(<Component />, container); React.unmountComponentAtNode(container); expect(innerUnmounted).toBe(true); // <Component />, <Inner />, and both <div /> elements each call // unmountIDFromEnvironment which calls purgeID, for a total of 4. expect(ReactMount.purgeID.callCount).toBe(4); }); </ins> it('should detect valid CompositeComponent classes', function() { var Component = React.createClass({ render: function() {

Related discussion:
text: When unmounting components like this: a memory leak happens because ReactMount.getID(node) puts DOM nodes back to nodeCache if they are not there.. just right after they were purged from cache. Here is what's happing when unmounting that example component: label component gets purged from nodeCache when ReactDOMInput component is going to unmount it calls this method: which contains this.getDOMNode() which iterates through the children of the Form element calling getID() on each of them.. which puts these elements back into the cache. So first they were purged and here they are all put back in cache causing a memory leak :( I'm playing with React just 3rd day so not sure of a way to correctly fix this issue
(I took the liberty to edit your comment to add syntax highlighting)
I can't reproduce this. With this diff applied, I loaded http://127.0.0.1:8000/examples/ballmer-peak/ in the console and checked -- it was empty. Am I misunderstanding?
Yes. You've missed one more user defined component in there.. Here you go:
Thanks, fixed in .
Thank you for fast fix :)
Thanks for the find/fix!
Code change:
jsxScripts.push(scripts.item(i)); } } console.warn("You are using the in-browser JSX transformer. Be sure to precompile your JSX for production - http://facebook.github.io/react/docs/tooling-integration.html#jsx"); jsxScripts.forEach(function(script) {

Related discussion:
text: This makes it basically unusable in any nontrivial project. While people shouldn't be using this in production, we should still fix this bug for newbies and people using it for hackathons.
This should be relatively easy. What should we do with inline tags?
Code change:
function getJSReport(browser){ return browser <del> .waitForCondition("typeof window.jasmine != 'undefined'", 5e3) </del> <ins> .waitFor(wd.asserters.jsCondition("typeof window.jasmine != 'undefined'"), 5e3, 50) </ins> .fail(function(error){ throw Error("The test page didn't load properly. " + error); }) <del> .waitForCondition("typeof window.jasmine.getJSReport != 'undefined'", 10e3) .waitForCondition("window.postDataToURL.running <= 0", 30e3) </del> <ins> .waitFor(wd.asserters.jsCondition("typeof window.jasmine.getJSReport != 'undefined'"), 60e3, 100) .waitFor(wd.asserters.jsCondition("window.postDataToURL.running <= 0"), 30e3, 500) </ins> .eval("jasmine.getJSReport().passed"); }

Related discussion:
text: Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-
Code change:
var elementFactory = ReactElement.createFactory(tag); var FullPageComponent = ReactClass.createClass({ <ins> tagName: tag.toUpperCase(), </ins> displayName: 'ReactFullPageComponent' + tag, componentWillUnmount: function() {

Related discussion:
text: I’ve tried to update from react 0.12.2 to 0.13.0 which caused several unit tests of my project to fail. I use react to render html on the server side, this includes the basic html structure like , and elements. All unit tests dealing with such elements are failing with react 0.13.0 but they worked fine with 0.12.2. Here is a minimal example : Running this with react 0.12.2, correctly logs the text content of the title:Running this with react 0.13.0 throws a TypeError
I think this is just a bug, not an intentional breaking change. Thanks for reporting.
Code change:
expect(idCallOrder[0]).toBe(getID(CHILD)); }); <del> it('should stopPropagation if false is returned', function() { </del> <ins> it('should stopPropagation if false is returned, but warn', function() { </ins> ReactBrowserEventEmitter.putListener( getID(CHILD), ON_CLICK_KEY,

Related discussion:
text: We currently support this, but it makes code less understandable and we'd like to stop supporting it and encourage people to use either e.preventDefault() or e.stopPropagation() as appropriate.
:+1: And then free up the event handler's return value for something else.
you mean? :)
Maybe =) Otherwise we can always use it to indicate something in a potential future event system.