Question:
Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-

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"); }


Question:
Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-

urls.unshift('../node_modules/es5-shim/es5-shim.js'); } <del> var cacheBust = '?_=' + Date.now().toString(36); </del> <ins> var cacheBust = '?_=' + (+new Date).toString(36); </ins> for (var urls_index = -1, urls_length = urls.length; ++urls_index < urls_length;) { document.write('<script src="' + urls[urls_index] + cacheBust + '"></script>');


Question:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

* @protected */ setState: function(partialState, callback) { <ins> invariant( typeof partialState === 'object' || partialState == null, 'setState(...): takes an object of state variables to update.' ); if (__DEV__){ if (partialState == null) { console.warn( 'setState(...): You passed an undefined or null state object; ' + 'instead, use forceUpdate().' ); } } </ins> // Merge with `_pendingState` if it exists, otherwise with existing state. this.replaceState( merge(this._pendingState || this.state, partialState),


Question:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

checkMergeArrayArgs: function(one, two) { invariant( Array.isArray(one) && Array.isArray(two), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge arrays, instead got %s and %s.', one, two </ins> ); },


Question:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

checkMergeObjectArg: function(arg) { invariant( !isTerminal(arg) && !Array.isArray(arg), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge an object, instead got %s.', arg </ins> ); },


Question:
Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still). Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.

* CSS properties which accept numbers but are not in units of "px". */ var isUnitlessNumber = { <ins> columnCount: true, </ins> fillOpacity: true, <ins> flex: true, flexGrow: true, flexShrink: true, </ins> fontWeight: true, lineHeight: true, opacity: true, <ins> order: true, </ins> orphans: true, <ins> pitchRange: true, richness: true, stress: true, volume: true, widows: true, </ins> zIndex: true, zoom: true };


Question:
Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still). Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.

}); it('should not append `px` to styles that might need a number', function() { <del> expect(CSSPropertyOperations.createMarkupForStyles({ fillOpacity: 1, fontWeight: 2, opacity: 3, orphans: 4, zIndex: 5, zoom: 6, lineHeight: 7 })).toBe( 'fill-opacity:1;font-weight:2;opacity:3;orphans:4;z-index:5;zoom:6;' + 'line-height:7;' ); </del> <ins> var unitlessProperties = [ 'columnCount', 'fillOpacity', 'flex', 'flexGrow', 'flexShrink', 'fontWeight', 'lineHeight', 'opacity', 'order', 'orphans', 'pitchRange', 'richness', 'stress', 'volume', 'widows', 'zIndex', 'zoom' ]; unitlessProperties.forEach(function(property) { var styles = {}; styles[property] = 1; expect(CSSPropertyOperations.createMarkupForStyles(styles)) .toMatch(/:1;$/); }); </ins> }); it('should set style attribute when styles exist', function() {


Question:
When I run jsx --watch src/ build/ it compiles the jsx files and create a file in the build directory. On the next jsx file modification, the jsx process crashes. Once the is present, jsx won't compile jsx files even when ran manually. I use OSX Maverick and jsx 0.8.13.
AFAIK this is a "bug" with or whatever JSX relies on to expose that feature. Just make sure to close the watch instance instead of just closing the terminal/powering down and it should be fine.
Does it work again if you remove the file?
Yes it does. Oh or wait, the crashing.
It seems like there are two ways of fixing this. We can either out why is not cleaning up the file when the process exits, or the functionality and just hope people don't accidentally have multiple processes targeting the same output directory. I'm pretty comfortable with option 2, honestly. Thoughts,
Yeah, no lock seems fine for me, it could warn if it was found perhaps? Another thing to mention that has been happening to me, I'm using React through a Linux VM and accessing the filesystem through samba. When saving a file it immediately triggers a recompile before the file has finished saving, causing it to error. Shortly after it recompiles it again, so no harm, but it's worth noting.
I'm fine with no locking. I didn't even know that existed. Do what works!

"url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.8.14", </del> <ins> "commoner": "~0.9.0", </ins> "esprima-fb": "~2001.1001.0-dev-harmony-fb", "jstransform": "~2.0.2" },


Question:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

var mocks = require('mocks'); <ins> var ExecutionEnvironment; </ins> var React; <ins> var ReactMarkupChecksum; </ins> var ReactMount; <ins> var ReactReconcileTransaction; </ins> var ReactTestUtils; var ReactServerRendering; <del> var ReactMarkupChecksum; var ExecutionEnvironment; </del> var ID_ATTRIBUTE_NAME;


Question:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); <ins> ReactMarkupChecksum = require('ReactMarkupChecksum'); </ins> ReactMount = require('ReactMount'); ReactTestUtils = require('ReactTestUtils'); <ins> ReactReconcileTransaction = require('ReactReconcileTransaction'); </ins> ExecutionEnvironment = require('ExecutionEnvironment'); ExecutionEnvironment.canUseDOM = false; ReactServerRendering = require('ReactServerRendering'); <del> ReactMarkupChecksum = require('ReactMarkupChecksum'); </del> var DOMProperty = require('DOMProperty'); ID_ATTRIBUTE_NAME = DOMProperty.ID_ATTRIBUTE_NAME;


Question:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

'a valid ReactComponent.' ); }); <ins> it('allows setState in componentWillMount without using DOM', function() { var Component = React.createClass({ componentWillMount: function() { this.setState({text: 'hello, world'}); }, render: function() { return <div>{this.state.text}</div>; } }); ReactReconcileTransaction.prototype.perform = function() { // We shouldn't ever be calling this on the server throw new Error('Browser reconcile transaction should not be used'); }; var markup = ReactServerRendering.renderComponentToString( <Component /> ); expect(markup.indexOf('hello, world') >= 0).toBe(true); }); </ins> }); });


Question:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

// componentDidUpdate) but we need to check here too in order to catch // updates enqueued by setState callbacks. while (dirtyComponents.length) { <ins> var allUnmounted = true; for (var i = 0, l = dirtyComponents.length; i < l; i++) { if (dirtyComponents[i].isMounted()) { allUnmounted = false; break; } } if (allUnmounted) { // All the "dirty" components are unmounted, which probably means that // they were marked dirty due to setState calls in componentWillMount // handlers and the components are currently in the process of mounting. // `runBatchedUpdates` will be a noop. In that case, initializing the // DOM-dependent ReactReconcileTransaction is thus not what we want to // do, especially when using server rendering, so we skip it. dirtyComponents.length = 0; return; } </ins> var transaction = ReactUpdatesFlushTransaction.getPooled(); transaction.perform(runBatchedUpdates, null, transaction); ReactUpdatesFlushTransaction.release(transaction);


Question:
At the end, there is a confusing explanation about "Duplicated data from props" in the section "What Shouldn’t Go in State?": Perhaps what is trying to be said is something like:
Ah, perhaps what they're really referring to is basically "edit pages", where you might want to diff the before and after, so that you can send only the changed variables. But it really reads quite weirdly, especially for beginners.
This change is needed. I'm new to React and just did a Google search on that part of the documentation for clarification and it came up with this page. I'm guessing that what you've interpreted it to mean is correct, as it makes sense that way.

* **Computed data:** Don't worry about precomputing values based on state — it's easier to ensure that your UI is consistent if you do all computation within `render()`. For example, if you have an array of list items in state and you want to render the count as a string, simply render `this.state.listItems.length + ' list items'` in your `render()` method rather than storing it on state. * **React components:** Build them in `render()` based on underlying props and state. <del> * **Duplicated data from props:** Try to use props as the source of truth where possible. Because props can change over time, it's appropriate to store props in state to be able to know its previous values. </del> <ins> * **Duplicated data from props:** Try to use props as the source of truth where possible. One valid use to store props in state is to be able to know it's previous values, because props can change over time. </ins>


Question: Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.

invariant( one[key] === undefined, 'mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: %s', </del> <ins> 'Tried to merge two objects with the same key: `%s`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.', </ins> key ); one[key] = value;


Question: Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.

instance = ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: x' </del> <ins> 'Tried to merge two objects with the same key: `x`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.' </ins> ); });


Question:
Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1

<ins> /** * Copyright 2014-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'; require('mock-modules') .dontMock('shallowEqual'); var shallowEqual; describe('shallowEqual', function() { beforeEach(function() { shallowEqual = require('shallowEqual'); }); it('returns false if either argument is null', function() { expect(shallowEqual(null, {})).toBe(false); expect(shallowEqual({}, null)).toBe(false); }); it('returns true if both arguments are null or undefined', function() { expect(shallowEqual(null, null)).toBe(true); expect(shallowEqual(undefined, undefined)).toBe(true); }); it('returns true if arguments are shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2, c: 3} ) ).toBe(true); }); it('returns false if first argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2} ) ).toBe(false); }); it('returns false if second argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2}, {a: 1, b: 2, c: 3} ) ).toBe(false); }); it('returns false if arguments are not shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: {}}, {a: 1, b: 2, c: {}} ) ).toBe(false); }); }); </ins>


Question:
Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1

if (objA === objB) { return true; } <ins> if (!objA || !objB) { return false; } </ins> var key; // Test for A's keys different from B. for (key in objA) {


Question:
! 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.

HTML to JSX Compiler


Question:
Idea (that I'm pretty sure I saw elsewhere, react-native maybe?)… We should transform our calls to a conditional wrapping the call. We have to check the condition anyway and this would reduce the no-op function calls. In otherwords becomes Hell, we could replace the with and get rid of the function call entirely, though it really doesn't matter much since we're going to throw (plus we'd duplicate the default string). This might end up be a meaningless optimization…
I believe this is done intentionally (by hand) in some hotspots, so it would seem not. I guess one could argue if it might not make more sense to simply always use the inline style and drop the argument rather than adding another transform?
That's a tough sentence to parse. Are you saying we should always write the "optimized" form? If so I would say "no", the first is way easier to read as a human being.
do you consider something like since jsx has to be transformed anyways? invariant feels more like a contract to me and codes could be more readable if we separate the warning and real implementation, any thoughts?
We have complex invariants that aren't strictly about arguments so while that might be an option for some cases, it doesn't cover us.

}, "preferGlobal": true, "commonerConfig": { <del> "version": 6 </del> <ins> "version": 7 </ins> }, "scripts": { "test": "jest",


Question:
Idea (that I'm pretty sure I saw elsewhere, react-native maybe?)… We should transform our calls to a conditional wrapping the call. We have to check the condition anyway and this would reduce the no-op function calls. In otherwords becomes Hell, we could replace the with and get rid of the function call entirely, though it really doesn't matter much since we're going to throw (plus we'd duplicate the default string). This might end up be a meaningless optimization…
I believe this is done intentionally (by hand) in some hotspots, so it would seem not. I guess one could argue if it might not make more sense to simply always use the inline style and drop the argument rather than adding another transform?
That's a tough sentence to parse. Are you saying we should always write the "optimized" form? If so I would say "no", the first is way easier to read as a human being.
do you consider something like since jsx has to be transformed anyways? invariant feels more like a contract to me and codes could be more readable if we separate the warning and real implementation, any thoughts?
We have complex invariants that aren't strictly about arguments so while that might be an option for some cases, it doesn't cover us.

CallExpression: { exit: function(node, parent) { if (this.get('callee').isIdentifier({name: 'invariant'})) { <del> // Truncate the arguments of invariant(condition, ...) // statements to just the condition based on NODE_ENV // (dead code removal will remove the extra bytes). return t.conditionalExpression( DEV_EXPRESSION, node, t.callExpression(node.callee, [node.arguments[0]]) </del> <ins> // Turns this code: // // invariant(condition, argument, argument); // // into this: // // if (!condition) { //   if ("production" !== process.env.NODE_ENV) { //     invariant(false, argument, argument); //   } else { //     invariant(false); //   } // } // // Specifically this does 2 things: // 1. Checks the condition first, preventing an extra function call. // 2. Adds an environment check so that verbose error messages aren't //    shipped to production. // The generated code is longer than the original code but will dead // code removal in a minifier will strip that out. var condition = node.arguments[0]; return t.ifStatement( t.unaryExpression('!', condition), t.blockStatement([ t.ifStatement( DEV_EXPRESSION, t.blockStatement([ t.expressionStatement( t.callExpression( node.callee, [t.literal(false)].concat(node.arguments.slice(1)) ) ) ]), t.blockStatement([ t.expressionStatement( t.callExpression( node.callee, [t.literal(false)] ) ) ]) ) ]) </ins> ); } else if (this.get('callee').isIdentifier({name: 'warning'})) { <del> // Eliminate warning(condition, ...) statements based on NODE_ENV // (dead code removal will remove the extra bytes). return t.conditionalExpression( </del> <ins> // Turns this code: // // warning(condition, argument, argument); // // into this: // // if ("production" !== process.env.NODE_ENV) { //   warning(condition, argument, argument); // } // // The goal is to strip out warning calls entirely in production. We // don't need the same optimizations for conditions that we use for // invariant because we don't care about an extra call in __DEV__ return t.ifStatement( </ins> DEV_EXPRESSION, <del> node, t.literal(null) </del> <ins> t.blockStatement([ t.expressionStatement( node ) ]) </ins> ); } }


Question: The attribute allows for restrictions to be placed on iframes, regardless of domain. It's useful if you're dealing with IE versions less than 10 that don't have the attribute. More info: (v=vs.85).aspx

itemRef: MUST_USE_ATTRIBUTE, // property is supported for OpenGraph in meta tags. property: null, <ins> // IE-only attribute that specifies security restrictions on an iframe // as an alternative to the sandbox attribute on IE<10 security: MUST_USE_ATTRIBUTE, </ins> // IE-only attribute that controls focus behavior unselectable: MUST_USE_ATTRIBUTE, },


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

var grunt = require('grunt'); var UglifyJS = require('uglify-js'); var uglifyify = require('uglifyify'); <del> var _ = require('lodash'); </del> <ins> var derequire = require('derequire'); </ins> var SIMPLE_TEMPLATE = '/**n


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

debug: false, standalone: 'React', transforms: [envify({NODE_ENV: 'development'})], <del> after: [es3ify.transform, simpleBannerify] </del> <ins> after: [es3ify.transform, derequire, simpleBannerify] </ins> }; <del> var min = _.merge({}, basic, { </del> <ins> var min = { entries: [ './build/modules/React.js' ], </ins> outfile: './build/react.min.js', debug: false, <ins> standalone: 'React', </ins> transforms: [envify({NODE_ENV: 'production'}), uglifyify], <del> after: [minify, bannerify] }); </del> <ins> after: [es3ify.transform, derequire, minify, bannerify] }; </ins> var transformer = { entries:[


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

outfile: './build/JSXTransformer.js', debug: false, standalone: 'JSXTransformer', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; var addons = {


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

outfile: './build/react-with-addons.js', debug: false, standalone: 'React', <del> transforms: [envify({NODE_ENV: 'development'})], </del> packageName: 'React (with addons)', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [envify({NODE_ENV: 'development'})], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; <del> var addonsMin = _.merge({}, addons, { </del> <ins> var addonsMin = { entries: [ './build/modules/ReactWithAddons.js' ], </ins> outfile: './build/react-with-addons.min.js', debug: false, <ins> standalone: 'React', packageName: 'React (with addons)', </ins> transforms: [envify({NODE_ENV: 'production'}), uglifyify], <del> after: [minify, bannerify] }); </del> <ins> after: [es3ify.transform, derequire, minify, bannerify] }; </ins> var withCodeCoverageLogging = { entries: [


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

// grunt.config.requires('entries'); config.transforms = config.transforms || []; config.after = config.after || []; <del> if (typeof config.after === 'function') { config.after = [config.after]; } </del> // create the bundle we'll work with var entries = grunt.file.expand(config.entries); <del> var bundle = browserify(entries); // Make sure the things that need to be exposed are. var requires = config.requires || {}; if (requires instanceof Array) { grunt.file.expand({ nonull: true, // Keep IDs that don't expand to anything. cwd: "src" }, requires).forEach(function(name) { bundle.require("./build/modules/" + name, { expose: name.replace(/.js$/i, "") }); }); } else if (typeof requires === "object") { Object.keys(requires).forEach(function(name) { bundle.require(requires[name], { expose: name }); }); } </del> // Extract other options var options = { <ins> entries: entries, </ins> debug: config.debug, // sourcemaps standalone: config.standalone // global }; <del> // TODO: make sure this works, test with this too </del> <ins> var bundle = browserify(options); </ins> config.transforms.forEach(function(transform) { bundle.transform({}, transform); }); // Actually bundle it up var _this = this; <del> bundle.bundle(options, function(err, src) { </del> <ins> bundle.bundle(function(err, buf) { </ins> if (err) { grunt.log.error(err); <del> done(); </del> <ins> return done(); </ins> } <ins> var src = buf.toString(); </ins> config.after.forEach(function(fn) { src = fn.call(_this, src); });


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

"node": ">=0.10.0" }, "dependencies": { <del> "envify": "^2.0.0" </del> <ins> "envify": "^3.0.0" </ins> }, "browserify": { "transform": ["envify"]


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

"dependencies": { "commoner": "^0.10.0", "esprima-fb": "^6001.1.0-dev-harmony-fb", <del> "jstransform": "^6.2.0" </del> <ins> "jstransform": "^6.3.2" </ins> }, "devDependencies": { "benchmark": "~1.0.0", <del> "browserify": "^4.1.10", </del> <ins> "browserify": "^6.1.0", </ins> "coverify": "~1.0.4", <del> "envify": "^2.0.0", </del> <ins> "derequire": "^1.2.0", "envify": "^3.0.0", </ins> "es3ify": "~0.1.2", "es5-shim": "^4.0.0", "grunt": "~0.4.2", "grunt-cli": "~0.1.9", "grunt-compare-size": "~0.4.0", <del> "grunt-contrib-clean": "~0.5.0", "grunt-contrib-compress": "^0.9.1", </del> <ins> "grunt-contrib-clean": "^0.6.0", "grunt-contrib-compress": "^0.12.0", </ins> "grunt-contrib-connect": "~0.6.0", <del> "grunt-contrib-copy": "~0.5.0", </del> <ins> "grunt-contrib-copy": "^0.6.0", </ins> "grunt-contrib-jshint": "^0.10.0", "gzip-js": "~0.3.2", "jasmine-tapreporter": "~0.2.2", "jest-cli": "~0.1.5", "lodash": "~2.4.1", <del> "microtime": "^0.6.0", </del> "optimist": "~0.6.0", "phantomjs": "~1.9", "platform": "^1.1.0", "populist": "~0.1.6", <del> "recast": "^0.6.10", </del> <ins> "recast": "^0.7.2", </ins> "sauce-tunnel": "~1.1.0", <del> "semver": "^2.3.0", </del> "tmp": "~0.0.18", "uglify-js": "~2.4.0", "uglifyify": "^2.4.0",


Question:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

"rootDir": "", "scriptPreprocessor": "jest/preprocessor.js", "setupEnvScriptFile": "jest/environment.js", <del> "modulePathIgnorePatterns": ["/build/", "/node_modules/", "/.module-cache/"], "testPathIgnorePatterns": ["/build/", "/node_modules/"], "unmockedModulePathPatterns": [""] </del> <ins> "modulePathIgnorePatterns": [ "/build/", "/node_modules/", "/.module-cache/" ], "testPathIgnorePatterns": [ "/build/", "/node_modules/" ], "unmockedModulePathPatterns": [ "" ] </ins> } }


Question:
Do you want to request a feature or report a bug? Bug. What is the current behavior? Right now, React provides a cross-browser workaround for the event. , so React hacks around this by evaluating the selection after both and , which is smart! However, if you haven't an handler to your component, the part of the selection listening hack for Firefox won't ever fire. Which means if you happen to be doing something in that changes the selection, it won't be caught by as expected, such that the next time fires, the handler will be triggered (via the part of the hack), since React thinks the selection has changed. Example: You place your cursor at the end of a sentence. fires thanks to . updates the selection. You the last character: you handle deleting the character, and preventing default. doesn't fire, because on change hasn't taken place yet, as expected. updates the selection. You another character: you handle deleting another character. fires thanks to , but its internal state is comparing it to the selection before it was updated by , so it is out of date. Not expected. If you add a noop handler for , this problem goes away, since will always fire after rendering thanks to , and then it will never fire incorrectly due to . An example is in , actually doesn't do anything. Except without, the handling wouldn't stay in sync in Firefox. What is the expected behavior? Ideally I'd think that the event hack would still fire even without having to have the developer add a noop to their component? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15 in Firefox.
Thanks for the detailed report Sorry I didn't get to this until now. This should be an easy fix – just adding onKeyUp below onKeyDown here:

topLevelTypes.topContextMenu, topLevelTypes.topFocus, topLevelTypes.topKeyDown, <ins> topLevelTypes.topKeyUp, </ins> topLevelTypes.topMouseDown, topLevelTypes.topMouseUp, topLevelTypes.topSelectionChange,


Question:
There appears to be a typo on line 116 of "codebase-". Specifically, I see one "" symbol. This results in all text after line 116 appearing as one large block of code. See the screenshot below, with the markdown code on the left and the stylized code rendered on the right: <img width="1389" alt="screen shot 2017-01-09 at 2 38 51 pm" src=""Based on the content of the subsequent text after line 116, I would expect it to appear as the following: <img width="1436" alt="screen shot 2017-01-09 at 2 42 08 pm" src=""If this is indeed something that should be fixed, I'd like to fix it, and can submit a PR immediately.
I think you're right, please do submit a PR.
(For future reference, feel free to send PRs for small fixes like this without creating an issue.)

It is a good idea to avoid spamming the console with duplicate warnings: <del> ````js </del> <ins> ```js </ins> var warning = require('warning'); var didWarnAboutMath = false;


Question:
Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!
I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!

In a traditional JavaScript application, you need to look at what data changed and imperatively make changes to the DOM to keep it up-to-date. Even AngularJS, <del> which provides a declarative interface via directives and data binding requires a linking function to manually update DOM nodes. </del> <ins> which provides a declarative interface via directives and data binding [requires a linking function to manually update DOM nodes](http://docs.angularjs.org/guide/directive#reasonsbehindthecompilelinkseparation). </ins> React takes a different approach.


Question:
Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!
I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!

- Facebook has dynamic charts that render to `<canvas>` instead of HTML. - Instagram is a "single page" web app built entirely with React and `Backbone.Router`. Designers regularly contribute React code with JSX. <del> - We've built an internal prototype that runs React apps in a web worker. </del> <ins> - We've built internal prototypes that run React apps in a web worker and use React to drive **native iOS views** via an Objective-C bridge. </ins> - You can run React [on the server](http://github.com/petehunt/react-server-rendering) for SEO, performance, code sharing and overall flexibility.


Question:
<!-- 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? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens. ~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.

ReactCache = require('react-cache'); Suspense = React.Suspense; container = document.createElement('div'); <ins> document.body.appendChild(container); </ins> TextResource = ReactCache.unstable_createResource(([text, ms = 0]) => { return new Promise((resolve, reject) =>


Question:
<!-- 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? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens. ~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.

}, ([text, ms]) => text); }); <ins> afterEach(() => { document.body.removeChild(container); }); </ins> function advanceTimers(ms) { // Note: This advances Jest's virtual time but not React's. Use // ReactNoop.expire for that.


Question:
<!-- 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? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens. ~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.

); }, ); <ins> // Regression test for https://github.com/facebook/react/issues/14188 it('can call findDOMNode() in a suspended component commit phase', async () => { const log = []; const Lazy = React.lazy( () => new Promise(resolve => resolve({ default() { return 'lazy'; }, }), ), ); class Child extends React.Component { componentDidMount() { log.push('cDM ' + this.props.id); ReactDOM.findDOMNode(this); } componentDidUpdate() { log.push('cDU ' + this.props.id); ReactDOM.findDOMNode(this); } render() { return 'child'; } } const buttonRef = React.createRef(); class App extends React.Component { state = { suspend: false, }; handleClick = () => { this.setState({suspend: true}); }; render() { return ( <React.Suspense fallback="Loading"> <Child id="first" /> <button ref={buttonRef} onClick={this.handleClick}> Suspend </button> <Child id="second" /> {this.state.suspend && <Lazy />} </React.Suspense> ); } } ReactDOM.render(<App />, container); expect(log).toEqual(['cDM first', 'cDM second']); log.length = 0; buttonRef.current.dispatchEvent(new MouseEvent('click', {bubbles: true})); await Lazy; expect(log).toEqual(['cDU first', 'cDU second']); }); </ins> });


Question:
I’ve seen the “rendered fewer hooks than expected” invariant a couple times now pointing at a component rendered as a part of an error boundary that just caught an error when that component does not use hooks at all. I’ve been able to fix this issue by un-commenting: I haven’t been able to produce a minimal test-case yet . I’m reporting anyway with the temporary fix that worked for me in case you have any insight on what a minimal test-case could be. I’ll update this issue if I keep running into the problem and I can create a minimal test-case.
I ran into the issue again and was able to produce a small repro: Pressing the “throw” button results in the invariant: With a component stack of: Which is weird since has no hooks!
Wanna look into fixing? Should be easy — there must be a missing call somewhere. Or maybe doesn't reset everything we need.
I looked into it, wrote a test, and discovered it’s fixed on master The test is broken on 16.8.6, I didn’t bother bisecting to find the commit that fixed it. PR for the test: .
I thought I was seeing this in 16.9, but it turns out we were on and , and both need to be updated for this to work.

Scheduler.flushAll(); expect(root).toMatchRenderedOutput('hello'); }); <ins> // Regression test for https://github.com/facebook/react/issues/15732 it('resets hooks when an error is thrown in the middle of a list of hooks', async () => { const {useEffect, useState} = React; class ErrorBoundary extends React.Component { state = {hasError: false}; static getDerivedStateFromError() { return {hasError: true}; } render() { return ( <Wrapper> {this.state.hasError ? 'Error!' : this.props.children} </Wrapper> ); } } function Wrapper({children}) { return children; } let setShouldThrow; function Thrower() { const [shouldThrow, _setShouldThrow] = useState(false); setShouldThrow = _setShouldThrow; if (shouldThrow) { throw new Error('Throw!'); } useEffect(() => {}, []); return 'Throw!'; } const root = ReactTestRenderer.create( <ErrorBoundary> <Thrower /> </ErrorBoundary>, ); expect(root).toMatchRenderedOutput('Throw!'); act(() => setShouldThrow(true)); expect(root).toMatchRenderedOutput('Error!'); }); </ins> });


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

} case Profiler: if (enableProfilerTimer) { <del> workInProgress.effectTag |= Update; </del> <ins> // Profiler should only call onRender when one of its descendants actually rendered. const hasChildWork = workInProgress.childExpirationTime >= renderExpirationTime; if (hasChildWork) { workInProgress.effectTag |= Update; } </ins> } break; case SuspenseComponent: {


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

); }); <ins> it('does not report work done on a sibling', () => { const callback = jest.fn(); const DoesNotUpdate = React.memo(function DoesNotUpdateInner() { Scheduler.unstable_advanceTime(10); return null; }, () => true); let updateProfilerSibling; function ProfilerSibling() { const [count, setCount] = React.useState(0); updateProfilerSibling = () => setCount(count + 1); return null; } function App() { return ( <React.Fragment> <React.Profiler id="test" onRender={callback}> <DoesNotUpdate /> </React.Profiler> <ProfilerSibling /> </React.Fragment> ); } const renderer = ReactTestRenderer.create(<App />); expect(callback).toHaveBeenCalledTimes(1); let call = callback.mock.calls[0]; expect(call).toHaveLength(enableSchedulerTracing ? 7 : 6); expect(call[0]).toBe('test'); expect(call[1]).toBe('mount'); expect(call[2]).toBe(10); // actual time expect(call[3]).toBe(10); // base time expect(call[4]).toBe(0); // start time expect(call[5]).toBe(10); // commit time expect(call[6]).toEqual(enableSchedulerTracing ? new Set() : undefined); // interaction events callback.mockReset(); Scheduler.unstable_advanceTime(20); // 10 -> 30 // Updating a parent should report a re-render, // since React technically did a little bit of work between the Profiler and the bailed out subtree. renderer.update(<App />); expect(callback).toHaveBeenCalledTimes(1); call = callback.mock.calls[0]; expect(call).toHaveLength(enableSchedulerTracing ? 7 : 6); expect(call[0]).toBe('test'); expect(call[1]).toBe('update'); expect(call[2]).toBe(0); // actual time expect(call[3]).toBe(10); // base time expect(call[4]).toBe(30); // start time expect(call[5]).toBe(30); // commit time expect(call[6]).toEqual(enableSchedulerTracing ? new Set() : undefined); // interaction events callback.mockReset(); Scheduler.unstable_advanceTime(20); // 30 -> 50 // Updating a sibling should not report a re-render. ReactTestRenderer.act(updateProfilerSibling); expect(callback).not.toHaveBeenCalled(); }); </ins> it('logs render times for both mount and update', () => { const callback = jest.fn();


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="parent" onRender={callback}> <AdvanceTime byAmount={10}> <React.Profiler id="child" onRender={callback}>


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

</React.Profiler> </AdvanceTime> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="first" onRender={callback}> <AdvanceTime byAmount={20} /> </React.Profiler> <React.Profiler id="second" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <AdvanceTime byAmount={20} /> <React.Profiler id="test" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <AdvanceTime byAmount={20} /> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(1);


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

} } <del> class Pure extends React.PureComponent { render() { return this.props.children; } } </del> const renderer = ReactTestRenderer.create( <React.Profiler id="outer" onRender={callback}> <Updater> <del> <React.Profiler id="middle" onRender={callback}> <Pure> <React.Profiler id="inner" onRender={callback}> <div /> </React.Profiler> </Pure> </del> <ins> <React.Profiler id="inner" onRender={callback}> <div /> </ins> </React.Profiler> </Updater> </React.Profiler>, ); // All profile callbacks are called for initial render <del> expect(callback).toHaveBeenCalledTimes(3); </del> <ins> expect(callback).toHaveBeenCalledTimes(2); </ins> callback.mockReset();


Question:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks

}); }); <del> // Only call profile updates for paths that have re-rendered // Since "inner" is beneath a pure component, it isn't called expect(callback).toHaveBeenCalledTimes(2); expect(callback.mock.calls[0][0]).toBe('middle'); expect(callback.mock.calls[1][0]).toBe('outer'); </del> <ins> // Only call onRender for paths that have re-rendered. // Since the Updater's props didn't change, // React does not re-render its children. expect(callback).toHaveBeenCalledTimes(1); expect(callback.mock.calls[0][0]).toBe('outer'); </ins> }); it('decreases actual time but not base time when sCU prevents an update', () => {