Question: 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;

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!


Question: expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('identifies elements, but not JSON, if Symbols are supported', function() { // Rudimentary polyfill // Once all jest engines support Symbols natively we can swap this to test

The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.


Question: return ( <div> <button onClick={this.handleAdd}>Aggiungi Elemento</button> <del> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </ins> {items} </ReactCSSTransitionGroup> </div>

When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..


Question: 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) {

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


Question: topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ) { var chars;

I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.


Question: */ getListener: function(inst, registrationName) { var bankForRegistrationName = listenerBank[registrationName]; <del> return bankForRegistrationName && bankForRegistrationName[inst._rootNodeID]; </del> <ins> var key = getDictionaryKey(inst); return bankForRegistrationName && bankForRegistrationName[key]; </ins> }, /**

In my javascript frameworks benchmark I ran into a performance regression for react. To reproduce open and open the console. Repeat three times the following: Click "Create 10,000" then click "Clear" You'll get a result like that: runLots took 1905. clear took 1997. runLots took 1813. clear took 4208.895 runLots took 1806. clear took 401. Now repeat the same for and you'll get something like that: unLots took 2938. clear took 399. runLots took 2726.365 clear took 383. runLots took 2872.625 clear took 381. (Measurement on Chrome 51 on MacOS 10.11.5 on a MBP 15) Notice that clear is a lot slower for the first two runs for React v 15, but the third clear run performs about the same for both react versions. The source code can be found in the of my benchmark.
In general we don’t advise you to render 10K items. Use something like instead. However, this indeed seems like a perf regression. <sIt appears that we’re spending a little time in per each item, and it adds up with 10K items.</s(Scratch that, doesn’t appear to be the cause.)
This is a very simple scenario: we are unmounting 10,000 components. The bottleneck is somewhere in reconciliation. React 0.14 is reconciling fast right away: <img width="762" alt="screen shot 2016-07-08 at 22 06 01" src=""React 15 is reconciling slow at first (notice how long is compared to applying DOM updates): <img width="1097" alt="screen shot 2016-07-08 at 22 03 56" src=""But it warms up exactly after two mount-unmount cycles (notice how its size is less relative to DOM updates): <img width="928" alt="screen shot 2016-07-08 at 22 04 07" src=""
It looks like there is some sort of V8 optimization that doesn’t kick in until you unmount a lot of components.

I was able to drastically reduce time (from 2 seconds to 300 milliseconds) on React 15 by replacing statements with assignment in these two places:   This is probably not a real solution (I think just leaving them as means memory keeps growing, even if just for property keys). Still, I wonder why 0.14.x is not similarly penalized.
Replacing objects with ES6 Maps gives similar performance improvements there.
This was fixed in . Thank you very much for caring and providing specific instructions.
As a quick experiment, I ran the benchmarks under Firefox: both versions ran in the same speed as the 15.2 in Chrome (I mean: slow). I surely hope the fix would fix it in Firefox too !
Maybe putting these fields on the internal instances instead of global maps will help it in Firefox. Would you like to investigate why it's slow?
I gave it a look, and Firefox slowness is due to DOM being slow. I don’t think we can fix it.
I'd really appreciate a Firefox bug report with testcase here!
I filed with the information of this bug. I don't have the time to do a reduced testcase now though.
FWIW, removeChild is slow in Gecko because of layout. No idea whether setting display: none before removal or some such might speed up the process. It might help if done on the element on which removeChild is being called.
Thank you for filing!


Question:
var divStyle = { color: 'white', backgroundImage: 'url(' + imgUrl + ')',  WebkitTransition: 'all' // note the capital 'W' here   WebkitTransition: 'all', // note the capital 'W' here msTransition: 'all' // 'ms' is the only lowercase vendor prefix  }; React.renderComponent(
Hello World!
, mountNode); ```  Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W".   Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes [other than `ms`](http://www.andismith.com/blog/2012/02/modernizr-prefixed/) should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W".

We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't


Question: 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);

: 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


Question: registrationName, typeof listener ); <ins> var key = getDictionaryKey(inst); </ins> var bankForRegistrationName = listenerBank[registrationName] || (listenerBank[registrationName] = {}); <del> bankForRegistrationName[inst._rootNodeID] = listener; </del> <ins> bankForRegistrationName[key] = listener; </ins> var PluginModule = EventPluginRegistry.registrationNameModules[registrationName];

In my javascript frameworks benchmark I ran into a performance regression for react. To reproduce open and open the console. Repeat three times the following: Click "Create 10,000" then click "Clear" You'll get a result like that: runLots took 1905. clear took 1997. runLots took 1813. clear took 4208.895 runLots took 1806. clear took 401. Now repeat the same for and you'll get something like that: unLots took 2938. clear took 399. runLots took 2726.365 clear took 383. runLots took 2872.625 clear took 381. (Measurement on Chrome 51 on MacOS 10.11.5 on a MBP 15) Notice that clear is a lot slower for the first two runs for React v 15, but the third clear run performs about the same for both react versions. The source code can be found in the of my benchmark.
In general we don’t advise you to render 10K items. Use something like instead. However, this indeed seems like a perf regression. <sIt appears that we’re spending a little time in per each item, and it adds up with 10K items.</s(Scratch that, doesn’t appear to be the cause.)
This is a very simple scenario: we are unmounting 10,000 components. The bottleneck is somewhere in reconciliation. React 0.14 is reconciling fast right away: <img width="762" alt="screen shot 2016-07-08 at 22 06 01" src=""React 15 is reconciling slow at first (notice how long is compared to applying DOM updates): <img width="1097" alt="screen shot 2016-07-08 at 22 03 56" src=""But it warms up exactly after two mount-unmount cycles (notice how its size is less relative to DOM updates): <img width="928" alt="screen shot 2016-07-08 at 22 04 07" src=""
It looks like there is some sort of V8 optimization that doesn’t kick in until you unmount a lot of components.

I was able to drastically reduce time (from 2 seconds to 300 milliseconds) on React 15 by replacing statements with assignment in these two places:   This is probably not a real solution (I think just leaving them as means memory keeps growing, even if just for property keys). Still, I wonder why 0.14.x is not similarly penalized.
Replacing objects with ES6 Maps gives similar performance improvements there.
This was fixed in . Thank you very much for caring and providing specific instructions.
As a quick experiment, I ran the benchmarks under Firefox: both versions ran in the same speed as the 15.2 in Chrome (I mean: slow). I surely hope the fix would fix it in Firefox too !
Maybe putting these fields on the internal instances instead of global maps will help it in Firefox. Would you like to investigate why it's slow?
I gave it a look, and Firefox slowness is due to DOM being slow. I don’t think we can fix it.
I'd really appreciate a Firefox bug report with testcase here!
I filed with the information of this bug. I don't have the time to do a reduced testcase now though.
FWIW, removeChild is slow in Gecko because of layout. No idea whether setting display: none before removal or some such might speed up the process. It might help if done on the element on which removeChild is being called.
Thank you for filing!


Question: <del> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule cx */ /** * This function is used to mark string literals representing CSS class names * so that they can be transformed statically. This allows for modularization * and minification of CSS class names. * * In static_upstream, this function is actually implemented, but it should * eventually be replaced with something more descriptive, and the transform * that is used in the main stack should be ported for use elsewhere. * * @param string|object className to modularize, or an object of key/values. *                      In the object case, the values are conditions that *                      determine if the className keys should be included. * @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ 'use strict'; var warning = require('warning'); var warned = false; function cx(classNames) { if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className]; }).join(' '); } else { return Array.prototype.join.call(arguments, ' '); } } module.exports = cx; </del>

Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors


Question: props.defaultChecked = null; props.defaultValue = null; <del> props.checked = this.props.checked != null ? this.props.checked : this.state.checked; </del> var value = LinkedValueUtils.getValue(this); props.value = value != null ? value : this.state.value; <ins> var checked = LinkedValueUtils.getChecked(this); props.checked = checked != null ? checked : this.state.checked; </ins> props.onChange = this._handleChange; return input(props, this.props.children);

When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?


Question: function detectEvents() { var testEl = document.createElement('div'); var style = testEl.style; <ins> // On some platforms, in particular some releases of Android 4.x, // the un-prefixed "animation" and "transition" properties are defined on the // style object but the events that fire will still be prefixed, so we need // to check if the un-prefixed events are useable, and if not remove them // from the map if (!('AnimationEvent' in window)) { delete EVENT_NAME_MAP.animationend.animation; } if (!('TransitionEvent' in window)) { delete EVENT_NAME_MAP.transitionend.transition; } </ins> for (var baseEventName in EVENT_NAME_MAP) { var baseEvents = EVENT_NAME_MAP[baseEventName]; for (var styleName in baseEvents) {

ReactCSSTransitionGroup doesn't work properly on (at least) Android 4.2. I've narrowed it down to the code in which is finding and properties on the test element's object and so only registering and handlers, despite the fact that Android fires events. So the end of the transition isn't properly detected. I will do some more investigation and see if there's a safer way to do this detection on Android (I seem to recall seeing something similar before).
See this patch for the Dojo toolkit: - basically on some Android versions is not . Could this be fixed by changing the order the properties are checked, so that is checked for before ?
This is still an issue on Android 4.3 (or at least on Samsung Galaxy S3 with Android 4.3). However changing the webkitTransition and transition order as suggested by it fixes the issue.
Is TransitionEvent defined or undefined on that browser? When the unprefixed version exists it's better to use that in general because it's more forwards-compatible.


Question: var TestComponent; var TestComponentWithPropTypes; <ins> var TestComponentWithReverseSpec; </ins> var mixinPropValidator; var componentPropValidator;

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


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

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!


Question: <ins> /** * Copyright 2013-present, 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'; describe('DisabledInputUtils', function() { var React; var ReactDOM; var ReactTestUtils; var elements = ['button', 'input', 'select', 'textarea']; function expectClickThru(element) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(element)); expect(onClick.mock.calls.length).toBe(1); } function expectNoClickThru(element) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(element)); expect(onClick.mock.calls.length).toBe(0); } function mounted(element) { element = ReactTestUtils.renderIntoDocument(element); return element; } var onClick = jest.genMockFn(); elements.forEach(function(tagName) { describe(tagName, function() { beforeEach(function() { React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('should forward clicks when it starts out not disabled', function() { var element = React.createElement(tagName, { onClick: onClick, }); expectClickThru(mounted(element)); }); it('should not forward clicks when it starts out disabled', function() { var element = React.createElement(tagName, { onClick: onClick, disabled: true, }); expectNoClickThru(mounted(element)); }); it('should forward clicks when it becomes not disabled', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick }), container ); expectClickThru(element); }); it('should not forward clicks when it becomes disabled', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); expectNoClickThru(element); }); it('should work correctly if the listener is changed', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: false }), container ); expectClickThru(element); }); }); }); }); </ins>

The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.


Question: ); }); <ins> it('should work with a null getInitialState() return value', function() { var Component = React.createClass({ getInitialState: function() { return null; }, render: function() { return <span />; } }); expect(() => <Component />).not.toThrow(); }); it('should work with object getInitialState() return values', function() { var Component = React.createClass({ getInitialState: function() { return { occupation: 'clown' }; }, render: function() { return <span />; } }); var instance = <Component />; ReactTestUtils.renderIntoDocument(instance); expect(instance.state.occupation).toEqual('clown'); }); it('should throw with non-object getInitialState() return values', function() { [['an array'], 'a string', 1234].forEach(function(state) { var Component = React.createClass({ getInitialState: function() { return state; }, render: function() { return <span />; } }); var instance = <Component />; expect(function() { ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: Component.getInitialState(): ' + 'must return an object or null' ); }); }); </ins> it('should detect valid CompositeComponent classes', function() { var Component = React.createClass({ render: function() {

See Return a string from and call . You get this amazing error message:
We should probably add an that whatever is returned from is in fact an object.
Invariant all the things :)
This also seems to apply when using an array, not the string only. Which makes it a pretty real-world bug IMHO (compared to the weird string scenario). Or is there a reason you don't want states to be arrays?
This will happen whenever state is anything but an Object (I think there is a check in there for arrays). Since we use merge it needs to be an object, arrays are no good either.


Question: // to a SimpleMemoComponent to allow fast path updates. workInProgress.tag = SimpleMemoComponent; workInProgress.type = type; <ins> if (__DEV__) { validateFunctionComponentInDev(workInProgress, type); } </ins> return updateSimpleMemoComponent( current, workInProgress,

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0


Question: function getUnboundedScrollPosition(scrollable) { if (scrollable === window) { return { <del> x: document.documentElement.scrollLeft || document.body.scrollLeft, y: document.documentElement.scrollTop  || document.body.scrollTop </del> <ins> x: window.pageXOffset || document.documentElement.scrollLeft, y: window.pageYOffset || document.documentElement.scrollTop </ins> }; } return {

Do you want to request a feature or report a bug? Improvement What is the current behavior?  does not currently support the property. () is nice to have when you want to write key-specific handling—rather than input-specific (dependent on layout and modifier keys) handling. What is the expected behavior? already exposes a property. It should have a property as well. Currently, if you want to use the 's , you must access it through 's . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Affects React 16 and earlier (I assume).
I created the PR for this.
the above PR is stale and closed; should I pick this up? planning to replicate the same and follow the PR suggestions; any tips or idea?
Can you give me an idea of how widely supported it is?
According to it is supported in all major desktop browsers. Are there any plans to implement this? I am not sure whether I should mark it with until this issue is resolved or don't use it at all.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!


Question: onChange={this.handleCodeChange} className="playgroundStage" codeText={this.state.code} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXTabClassName =

is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !


Question: var React; var ReactDOM; var ReactDOMServer; <del> var ReactDOMFeatureFlags; </del> var ReactTestUtils; <ins> var ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </ins> describe('ReactComponent', () => { function normalizeCodeLocInfo(str) { return str && str.replace(/(at .+?:d+)/g, '(at **)');

When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.


Question: ReactPerf.printDOM(measurements); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isRunning state', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('start has no effect when already running', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('stop has no effect when already stopped', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); </ins> });

I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR


Question: */ 'use strict'; <del> var Circle = require('react-art/lib/Circle.art'); </del> <ins> var Circle = require('react-art/Circle'); </ins> var React = require('react'); var ReactART = require('react-art'); var Group = ReactART.Group;

It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.


Question: // promisified version of ReactDOM.render() function asyncReactDOMRender(reactElement, domElement) { <del> return new Promise(resolve => ReactDOM.render(reactElement, domElement, resolve), ); </del> <ins> return new Promise(resolve => { ReactDOM.render(reactElement, domElement); // We can't use the callback for resolution because that will not catch // errors. They're thrown. resolve(); }); </ins> } // performs fn asynchronously and expects count errors logged to console.error. // will fail the test if the count of errors logged is not equal to count.

I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.


Question: var ReactElementValidator = { createElement: function(type, props, children) { <ins> // We warn in this case but don't throw. We expect the element creation to // succeed and there will likely be errors in render. warning( type != null, 'React.createElement: type should not be null or undefined. It should ' + 'be a string (for DOM elements) or a ReactClass (for composite ' + 'components).' ); </ins> var element = ReactElement.createElement.apply(this, arguments); // The result can be nullish if a mock or a custom function is used.

I spent the last hour trying to fix an issue that was caused by me trying to render a when the actual variable was undefined. The root cause was me misinterpreting that would return the whole instead of just (which is my bad), but the error itself and the stack trace were extremely cryptic and it took me a while to even get a clue that the reason why it wasn't working was that I was just trying to render an undefined type. This is the actual exception: And here's the stack trace: ! You can see that, ultimately, execution comes crashing down when React tries to look at on my undefined type, which of course raises an exception. The reason why this was confusing to me is that the exception happened quite far away from the source cause and, as a secondary factor, this code worked completely fine before I started porting it to Browserify and made my mistake with . This lead me to a wild set of hypotheses as to why it wasn't working, such as assuming it might be due to a regression in React 0.12 (since it's been migrating from to and I thought might have been lagging behind), to thinking it could be a problem with itself. The reason why I raise this issue is that, since passing an type won't work anyway, it would make sense if React could check for and warn about it or maybe even raise an exception (since it would crash soon after anyway). My instance was a bit more extreme and if something like this happens to someone else they'll probably know where they screwed up in the first place, but some help from React would always be welcome!
Actually returns the whole react lib + the addons. The addons are just to the object you'd get if you did . I've been using browserify the whole time and this error just came up, after updating to 0.12.1. It was working fine before, so it seems kind of weird that it's throwing an error right now. If a dev could comment on this, that'd be great.
Yea, seems like it wouldn't be a bad idea to have a check in createElement. What was working fine before? createElement didn't really exist (it was in 0.11.x but would likely not have been used). And react/addons has always been the full React object with addons inserted.
Talked it through with on IRC, same cause just not via addons.

An undefined component was being used.
Yeah, I became aware of that when I figured out what the issue is, I was just thinking it would have been way more helpful if React had told me straight away that I was passing an undefined component to .
+1, I also had this issue (albeit for a different reason)
Thanks! :+1:
If you are giving the whole JSX code under the script tag of the HTML page, then the order of declaration of the components could cause this issue. When the inbuilt compiler sees a component which you've later declared in the code, it'll throw an error. However in plain terms, this just means that the component is missing.
Getting this Uncaught TypeError: Cannot read property 'createElement' of undefined Any solutions
Please ask on StackOverflow; this is hard to answer without seeing your complete code.
here is my code ...
is incorrect, should be There is no named export named . It is confusing because React is a CommonJS module, and since you’re using ES6 imports, Babel tries to map the semantics but they don’t match exactly. actually grabs from itself so you might just and use instead if it’s less confusing.
Woah, thank you for a nice clarification.


Question: validateDangerousTag(tag); this._tag = tag; this._renderedChildren = null; <ins> this._previousStyle = null; </ins> this._previousStyleCopy = null; this._rootNodeID = null; }

Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.


Question: }), ).toThrow('is not a function'); }); <ins> it('warns when setState is called from insertion effect setup', () => { function App(props) { const [, setX] = useState(0); useInsertionEffect(() => { setX(1); if (props.throw) { throw Error('No'); } }, [props.throw]); return null; } const root = ReactNoop.createRoot(); expect(() => act(() => { root.render(<App />); }), ).toErrorDev(['Warning: useInsertionEffect must not schedule updates.']); expect(() => { act(() => { root.render(<App throw={true} />); }); }).toThrow('No'); // Should not warn for regular effects after throw. function NotInsertion() { const [, setX] = useState(0); useEffect(() => { setX(1); }, []); return null; } act(() => { root.render(<NotInsertion />); }); }); it('warns when setState is called from insertion effect cleanup', () => { function App(props) { const [, setX] = useState(0); useInsertionEffect(() => { if (props.throw) { throw Error('No'); } return () => { setX(1); }; }, [props.throw, props.foo]); return null; } const root = ReactNoop.createRoot(); act(() => { root.render(<App foo="hello" />); }); expect(() => { act(() => { root.render(<App foo="goodbye" />); }); }).toErrorDev(['Warning: useInsertionEffect must not schedule updates.']); expect(() => { act(() => { root.render(<App throw={true} />); }); }).toThrow('No'); // Should not warn for regular effects after throw. function NotInsertion() { const [, setX] = useState(0); useEffect(() => { setX(1); }, []); return null; } act(() => { root.render(<NotInsertion />); }); }); </ins> }); describe('useLayoutEffect', () => {

Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?


Question: transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; mountImages.push(mountImage); index++;

We're currently not cleaning up strings from _mountImage after a component gets mounted. That memory could be freed. But the act of freeing the memory could be more expensive than it's worth. Needs proper benchmarks and a workaround.
I noticed this a little while ago. I'm not sure why we need to store it on the child instance in the first place -- PR incoming.


Question: unstable_continueExecution, unstable_wrapCallback, unstable_getCurrentPriorityLevel, <ins> unstable_IdlePriority, unstable_ImmediatePriority, unstable_LowPriority, unstable_NormalPriority, unstable_UserBlockingPriority, </ins> } from 'scheduler'; import { __interactionsRef,

<!-- 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? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost.

I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.


Question: /** * @param {ReactComponent} input Form component <ins> * @return {*} current checked status of the input either from checked prop *             or link. */ getChecked: function(input) { if (input.props.checkedLink) { _assertCheckedLink(input); return input.props.checkedLink.value; } return input.props.checked; }, /** * @param {ReactComponent} input Form component </ins> * @return {function} change callback either from onChange prop or link. */ getOnChange: function(input) { if (input.props.valueLink) { <del> _assertLink(input); </del> <ins> _assertValueLink(input); </ins> return _handleLinkedValueChange; <ins> } else if (input.props.checkedLink) { _assertCheckedLink(input); return _handleLinkedCheckChange; </ins> } return input.props.onChange; }

When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?


Question: if (inlineScriptCount > 1) { source += ' (' + inlineScriptCount + ')'; } <ins> } else if (dummyAnchor) { // Firefox has problems when the sourcemap source is a proper URL with a // protocol and hostname, so use the pathname. We could use just the // filename, but hopefully using the full path will prevent potential // issues where the same filename exists in multiple directories. dummyAnchor.href = source; source = dummyAnchor.pathname.substr(1); </ins> } map.sources = [source]; map.sourcesContent = [code]; return ( transformed.code + <del> '//# sourceMappingURL=data:application/json;base64,' + </del> <ins> 'n//# sourceMappingURL=data:application/json;base64,' + </ins> buffer.Buffer(JSON.stringify(map)).toString('base64') ); } else {

It was reported to me on IRC today and confirmed on master / FF nightly myself. Also
I should add that when there are no errors in the jsx file the page still renders correctly, but the behavior persists (cannot load source file). Errors are reported from lines that do not exist in html file which makes bugs hard to track down. Confirmed on Windows 7 and Firefox 29. I can add more details once I get back to work on Monday - just let me know what information you need. Thanks, -Eric
What exactly is the issue? If it's just source lines being "off/out of bounds" then it's possible that it's the old JSX issue where source lines reported by esprima are mysteriously offset. AFAIK it was never explicitly solved, but no one was able to reproduce it anymore, perhaps it struck again? Other than that, JSX is just sugar on-top of esprima (and source-map I assume), and I think even the above issue is/was, so I don't think JSX is necessarily the root cause here.
Hi thanks for responding. At the most general level, the problem I am trying to solve is this: I want to be able to use the JSXTransformer script and be able to see a useful version of my compiled JS script which (pre-compilation) had JSX in it. I want to do this so that when I make an error in my JSX-containing JS script I can get a useful error message and hopefully see where the problem is in my original script (or get some clue as to where the problem might be). As it stands now, when I have an error in my script, the console just complains about lines which do not exist in my HTML file (which is only a few lines). So it'll say there's an error in line 65 of even though is only 15 lines. Compounding the problem is that, even when there were no errors and the JSX compiled perfectly to JS and the JS file ran just fine, I still cannot see any sources other than the JSX compiler, the reactjs source and my jquery source. I can't see either a uncompiled or compiled version of my JSX-containing JS file. Instead, what I see is this: Hopefully that explains everything, but let me know if you're still confused. I can provide more info when/if you need it.

Thanks
When I tested last week I couldn't get the source map to do anything at all in Firefox.
Figured it out. I can't decide if it's a Firefox issue or something we're doing wrong, but is the problem. It seems when we pass URLs (eg "") here, Firefox chokes. If we pass a filename (eg "") the sourcemap is usable. So short term, I'm just going to pull off the actual filename and use that. Inline scripts don't appear to have been a problem (supporting my URL theory). cc from the Firefox devtools team, might be worth looking into on your end as well (can't remember if I filed that bug).
Can we keep the full path but drop the domain-part perhaps?
Good idea, I changed to doing that :)
would love a minimal test case. Can you repro with just mozilla/source-map, or only while using devtools?


Question: props = ReactDOMOption.getNativeProps(this, props); break; case 'select': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMSelect.mountWrapper(this, props, nativeParent); props = ReactDOMSelect.getNativeProps(this, props); break; case 'textarea': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMTextarea.mountWrapper(this, props, nativeParent); props = ReactDOMTextarea.getNativeProps(this, props); break;

Ref:
I'm taking a look at this as a first bug - from the docs and some testing, the event seems to be fired at the form element level rather than the form itself. That is to say: will not log on submit, but: will log on submit. Does this match the expected behaviour, and if so do we want the handler to be on the individual React.DOM form elements (i.e. so it is called when that element is invalid), or do we want it to bubble up to the parent (i.e. so it is called whenever at least one element in that form is invalid)?
We should match the DOM and fire it on the element (not the form). We already have support for these events which don't bubble. Most of our events are at the document level and then delegated but the ones which don't bubble need to be to specific elements on creation. Here's how we're doing it for forms and the submit & reset events: Thanks for taking this on! Feel free to get a PR up before it's completely ready if you have questions / need help.
Thanks Paul, good to know I was looking in the right place! Will update when I have had time to create a PR or if I need any help :) Cheers Tom
Hey, I've put together a PR at - it would be great to get your feedback on it. A couple of specific questions I had: should I handle automated testing of this? There's a lot of test code to look at and I'm unfamiliar with the React codebase, so I'm unsure if/how this should be tested. the splitting out of the logic make sense? Or do you think it would be better to have a separate statement for this bit, preceeding the other in , matching all the elements which need this setup, and then keep the other as is (minus the first ) Any feedback appreciated, this does seem to work but I'm totally new to the React code so not sure if the way I've gone about it is suitable or not! Cheers, Tom
Awesome!


Question: id: test-utils title: Test Utilities permalink: test-utils.html <del> prev: class-name-manipulation.html </del> <ins> prev: two-way-binding-helpers.html </ins> next: clone-with-props.html ---

Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors


Question: transition: function(animationType, finishCallback) { var node = React.findDOMNode(this); <ins> if (!node) { if (finishCallback) { finishCallback(); } return; } </ins> var className = this.props.name + '-' + animationType; var activeClassName = className + '-active'; var noEventTimeout = null;

I came across this, when using . When loading a route initially where the route handler is actually inside a and then removing it from the transition group leads to an . The weird thing is that it only happens on initial load of a nested route, not when the same view is being pulled up via the menu. I'm not sure if this is an issue related or if it belongs to . But the thing is that the component either returns a react element, or it returns . It seems like an edge case maybe, because it only happens in this specific initial render setup. It could be fixed, by adding a guard to the method of :
This was probably fixed by .
I don't think this is solved. It's easy to reproduce with React 0.12.2: just have the child return from . It's rather frustrating because some other developer may change the animated component to return when data is not ready, and not realize that this breaks the case when that component is inside the transition group.
Yup ran into this as well. If you pass a component to ReactCSSTransitionGroup that renders null you get this exception. Using React 0.12.1
Can you please reopen?
i've get the same exception, too. Hope this will be fixed soon.
is there anything stopping you people from implementing the suggested fix? :)
I'm encountering a similar issue.
I guess a PR would be welcome?
yeah, there is is!
I'm still seeing this issue. And can verify that it only happens when I return null. React with addons v0.13.3
Yes, the fix is in 0.14.
Ahh.. well that would explain things. How can I get my hands on 0.14?
Sorry – not released yet, but hopefully in the next few weeks. 0.14-beta is on npm (see the React blog).


Question: var event = SyntheticEvent.getPooled( eventTypes.change, targetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ); event.type = 'change'; EventPropagators.accumulateTwoPhaseDispatches(event);

I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.


Question: Component classses created by `createClass()` return instances of `ReactComponent` when called. Most of the time when you're using React you're either creating or consuming `ReactComponent`s. <del> ### DOMElement getDOMNode() </del> <ins> #### getDOMNode ```javascript DOMElement getDOMNode() ``` </ins> If this component has been mounted into the DOM, this returns the corresponding native browser DOM element. This method is useful for reading values out of the DOM, such as form field values and performing DOM measurements. <del> ### setProps(object nextProps) </del> <ins> #### setProps ```javascript setProps(object nextProps) ``` </ins> When you're integrating with an external JavaScript application you may want to signal a change to a React component rendered with `renderComponent()`. Simply call `setProps()` to change its properties and trigger a re-render. **Note:** This method can only be called on a root-level component. That is, it's only available on the component passed directly to `renderComponent()` and none of its children. If you're inclined to use `setProps()` on a child component, instead take advantage of reactive updates and pass the new prop to the child component when it's created in `render()`. <del> ### replaceProps(object nextProps) </del> <ins> #### replaceProps ```javascript replaceProps(object nextProps) ``` </ins> Like `setProps()` but deletes any pre-existing props that are not in nextProps. <del> ### ReactComponent transferPropsTo(ReactComponent targetComponent) </del> <ins> #### transferPropsTo ```javascript ReactComponent transferPropsTo(ReactComponent targetComponent) ``` </ins> Transfer properties from this component to a target component that have not already been set on the target component. This is usually used to pass down properties to the returned root component. `targetComponent`, now updated with some new props is returned as a convenience. <del> ### setState(object nextState) </del> <ins> #### setState ```javascript setState(object nextState) ``` </ins> Merges nextState with the current state. This is the primary method you use to trigger UI updates from event handlers and server request callbacks.

I have a fresh installation of Ubuntu 14.04 and installed compiled version of 10.38. failed on step with error 'make: g++: Command not found'. solves the problem. It make sense put g++ dependency into Prerequisites section.
That's kind of annoying but yea, we might need to do something like that. Compilers are a dependency for any binary npm module (which one of our dependencies depends on). Even contextify itself doesn't call out the need for g**. When you install node / npm via does it not install as well? It seems like it should since that's a requirement for many modules.
I used the recommended approach for . is not a part of installation. But I see your point, contextify setup on Windows even more .
The installation of build-essential is not 'optional'. It is a prerequisite for otherwise node-gyp will fail. The instructions for the Debian-based installation should reflect that build-essential is a prerequisite.
for installing g++ in fedora and other linux os use sudo yum install /usr/bin/g++ or sudo dnf install gcc-c++
fixed it for me (Ubuntu)
works for CentOS7, too. :)
What about Mac?


Question: }).toThrow(); expect(console.error.calls.length).toBe(2); expect(console.error.calls[0].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components). Check the render method of `ParentComp`.' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components). Check the render method of ' + '`ParentComp`.' </ins> ); expect(console.error.calls[1].args[0]).toBe( 'Warning: Only functions or strings can be mounted as React components.'

The following code: produces deep into React.
Yea, we can do better than that. On the plus side, looks like this error will actually log as in the near future (does for me in my browsers: Firefox Nightly, Chrome beta). We should be able to catch this in . Strings are ok. Functions are ok (I think, or will be). Objects with certain characteristics are ok (has a render function?)
No objects, just functions that return objects with a render function. I thought we had a warning for this already though.
We just look for .
Sorry for all the references above. Let me know how looks.
I'm still getting this error (I just installed the latest react version). Any ideas why it happens? Everything else bundles rather alright with browserify but the main client script doesn't run and flags with this error.
It's a long shot, but I just had the same error, and it turned out to be a component that I was including with further up the component hierarchy than it was actually being used. Once I removed the extra it ran just fine again. If it helps to narrow down the component, the hierarchy was Ancestor ChildList Child ChildList Child... (recursive). The Ancestor component was unnecessarily including the Child component. But again this is pure speculation since the error message was in no way indicative of the solution I found, so the problem in your case may be completely different :) Cheers
Yep, you are right, it was totally my own error. The error reporting should be better though. It seems like frontend scripts are better at this than bundling everything using browserify.
Thanks you saved me a lot of time ;) I had simply forgotten to add the on a react component. I agree that this error is pretty confusing, even with the message (which is what I got).
I just had the same issue that cosmith had. The TypeError really isn't very helpful. The real error is only tangentially related to types...
Did you see a warning in the console logged before the exception was thrown? There should be one.
good question. It was probably there, but I don't recall now. Why would that be a warning and not an exception itself?
For this case specifically, it's because we want to be able to inline calls to React.createElement () without changing runtime behavior which we can do only if createElement never throws.

Can it be made to only throw when not in ? Granted, even I don't like that idea very much... I'm not sure there's a better solution than just emitting a warning before everything explodes. At the end of the day the dev is just going to Google the error because it's completely opaque. Then they'll find this thread or something similar and move on with their lives.
Not sure if this will help someone in the future, but another way to get this same error ( ) is by referencing a component that hasn't been to module exports. So this will throw the error mentioned: This will fix it:
Hopefully we can make the toUpperCase error a little less cryptic. Just posted .
very nice :+1:
I was trying to do and was getting this error. Later found that, Element has inline css entry at its root <div. After Removing the entry it has been fixed.
I'm struggling with this error too. Any pointers? Here is my main app: And here is my I'm using the latest version of rect, reactify and browserify to compile
In your file check the exports line , there is a typo I guess, It should be
Thank you! You saved me much frustration :)
Thank you, that was the source of my bug too.
I had the same error trying to include a component inside the same component Error :
In 0.14, you'll get something like this message:
hey kinda late on this, but would it be possible to get the name of the invalid component? Let's say I try to use but is wrong. Would it be possible to say that it's that is failing the test? Would help finding and fixing the errors
This isn't possible without changing the transform, no. You can look at the stack trace to see where the error was.
the error is so confused, and difficult to trace the error
:+1:
Thank you do much! What a terrible error message!


Question: "url": "https://github.com/facebook/react/issues" }, "homepage": "https://github.com/facebook/react/tree/master/npm-react-dom", <del> "dependencies": { </del> <ins> "peerDependencies": { </ins> "react": "^0.15.0-alpha" } }

My project uses react, react-dom, and react-bootstrap. react-bootstrap requires react to be a peer dependency. react-dom includes react as a child dependency. So I must install react as a top-level dependency in order for react-bootstrap to work. Now I have two copies of react. When I try to use the Modal component in react-bootstrap, I get the error "Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's method, or you have multiple copies of React loaded". I can fix this by deleting the directory nodemodules/react-dom/nodemodules/react. Maybe react-dom should be changed so react is a peer dependency instead of a child dependency.
As far as I understand it; yeah it should be a peer dependency (cc ?). But dependencies are not child dependencies that's simply a result of how NPM2 unfortunately resolves version issues, so peer dependency is preferable, but a regular dependency is not wrong, you just have to be careful to avoid multiple installations.
I don't know what I did to cause react to be installed below react-dom. I had this: nodemodules/react-dom/nodemodules/react and also: node_modules/react. I can't find a way to reproduce that now.
It can happen quite stealthily when updating/etc in NPM2. I ran into the same issue recently. I'll reopen this for now because it really seems to me that it should be a peer dependency.
Any reason why it is a direct dependency in the first place? Was not the intend of npm's peerDependencies to cover this exact problem? (Avoid duplications of modules built around other module, like react and react-dom), just saying that seems there isn't a reason for react-dom to include react as a direct dependency
It probably should be a peerDep. I don't remember why I put it as a regular dep there… (I did addons-* with React as a peerDep).


Question:
container = null; });  it('should support onPress', () => { let buttonRef = React.createRef(); let events = []; function handleOnPress1() { events.push('press 1'); } function handleOnPress2() { events.push('press 2'); } function handleOnMouseDown() { events.push('mousedown'); } function handleKeyDown() { events.push('keydown'); } function Component() { return ( <Press onPress={handleOnPress1}> <Press onPress={handleOnPress2}> <button ref={buttonRef} onMouseDown={handleOnMouseDown} onKeyDown={handleKeyDown}> Press me! </button> </Press>   describe('onPressStart', () => { let onPressStart, ref; beforeEach(() => { onPressStart = jest.fn(); ref = React.createRef(); const element = ( <Press onPressStart={onPressStart}>
  </Press> );  }   ReactDOM.render(element, container); });   ReactDOM.render(<Component />, container);   it('is called after "pointerdown" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressStart).toHaveBeenCalledTimes(1); });   const mouseDownEvent = document.createEvent('Event'); mouseDownEvent.initEvent('mousedown', true, true); buttonRef.current.dispatchEvent(mouseDownEvent);   it('ignores emulated "mousedown" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('mousedown')); expect(onPressStart).toHaveBeenCalledTimes(1); });   const mouseUpEvent = document.createEvent('Event'); mouseUpEvent.initEvent('mouseup', true, true); buttonRef.current.dispatchEvent(mouseUpEvent);   // No PointerEvent fallbacks it('is called after "mousedown" event', () => { ref.current.dispatchEvent(createPointerEvent('mousedown')); expect(onPressStart).toHaveBeenCalledTimes(1); }); it('is called after "touchstart" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); expect(onPressStart).toHaveBeenCalledTimes(1); }); // TODO: complete delayPressStart tests // describe('delayPressStart', () => {}); });   expect(events).toEqual(['mousedown', 'press 2', 'press 1']);   describe('onPressEnd', () => { let onPressEnd, ref; beforeEach(() => { onPressEnd = jest.fn(); ref = React.createRef(); const element = ( <Press onPressEnd={onPressEnd}>
 </Press> ); ReactDOM.render(element, container); }); it('is called after "pointerup" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPressEnd).toHaveBeenCalledTimes(1); });   events = []; const keyDownEvent = new KeyboardEvent('keydown', { key: 'Enter', bubbles: true, cancelable: true,   it('ignores emulated "mouseup" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); ref.current.dispatchEvent(createPointerEvent('touchend')); ref.current.dispatchEvent(createPointerEvent('mouseup')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); // No PointerEvent fallbacks it('is called after "mouseup" event', () => { ref.current.dispatchEvent(createPointerEvent('mousedown')); ref.current.dispatchEvent(createPointerEvent('mouseup')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); it('is called after "touchend" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); ref.current.dispatchEvent(createPointerEvent('touchend')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); // TODO: complete delayPressStart tests // describe('delayPressStart', () => {}); }); describe('onPressChange', () => { let onPressChange, ref; beforeEach(() => { onPressChange = jest.fn(); ref = React.createRef(); const element = ( <Press onPressChange={onPressChange}>
 </Press> ); ReactDOM.render(element, container); }); it('is called after "pointerdown" and "pointerup" events', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressChange).toHaveBeenCalledTimes(1); expect(onPressChange).toHaveBeenCalledWith(true); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPressChange).toHaveBeenCalledTimes(2); expect(onPressChange).toHaveBeenCalledWith(false); }); }); describe('onPress', () => { let onPress, ref; beforeEach(() => { onPress = jest.fn(); ref = React.createRef(); const element = ( <Press onPress={onPress}>
 </Press> ); ReactDOM.render(element, container);  });  buttonRef.current.dispatchEvent(keyDownEvent); // press 1 should not occur as press 2 will preventDefault expect(events).toEqual(['keydown', 'press 2']);   it('is called after "pointerup" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPress).toHaveBeenCalledTimes(1); });  });  it('should support onPressStart and onPressEnd', () => { let divRef = React.createRef(); let events = [];   describe('onLongPress', () => { let onLongPress, ref; beforeEach(() => { onLongPress = jest.fn(); ref = React.createRef(); const element = ( <Press onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); }); it('is called if press lasts default delay', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY - 1); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); });   function handleOnPressStart() { events.push('onPressStart'); }   it('is not called if press is released before delay', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY - 1); ref.current.dispatchEvent(createPointerEvent('pointerup')); jest.advanceTimersByTime(1); expect(onLongPress).not.toBeCalled(); });   function handleOnPressEnd() { events.push('onPressEnd'); }   describe('delayLongPress', () => { it('can be configured', () => { const element = ( <Press delayLongPress={2000} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(1999); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); it('uses 10ms minimum delay length', () => { const element = ( <Press delayLongPress={0} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(9); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); /* it('compounds with "delayPressStart"', () => { const delayPressStart = 100; const element = ( <Press delayPressStart={delayPressStart} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(delayPressStart + DEFAULT_LONG_PRESS_DELAY - 1); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); */ }); });   function Component() { return ( <Press onPressStart={handleOnPressStart} onPressEnd={handleOnPressEnd}>
Press me!
   describe('onLongPressChange', () => { it('is called when long press state changes', () => { const onLongPressChange = jest.fn(); const ref = React.createRef(); const element = ( <Press onLongPressChange={onLongPressChange}>
  </Press> );  }   ReactDOM.render(element, container);   ReactDOM.render(<Component />, container);   ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY); expect(onLongPressChange).toHaveBeenCalledTimes(1); expect(onLongPressChange).toHaveBeenCalledWith(true); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onLongPressChange).toHaveBeenCalledTimes(2); expect(onLongPressChange).toHaveBeenCalledWith(false); }); }); describe('onLongPressShouldCancelPress', () => { it('if true it cancels "onPress"', () => { const onPress = jest.fn(); const onPressChange = jest.fn(); const ref = React.createRef(); const element = ( <Press onLongPress={() => {}} onLongPressShouldCancelPress={() => true} onPressChange={onPressChange} onPress={onPress}>
 </Press> ); ReactDOM.render(element, container); // NOTE: onPressChange behavior should not be affected ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressChange).toHaveBeenCalledTimes(1); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPress).not.toBeCalled(); expect(onPressChange).toHaveBeenCalledTimes(2); }); }); // TODO //describe('`onPress*` with movement', () => { //describe('within bounds of hit rect', () => { /** ┌──────────────────┐ *  │  ┌────────────┐  │ *  │  │ VisualRect │  │ *  │  └────────────┘  │ *  │     HitRect    X │ <= Move to X and release *  └──────────────────┘ */   const pointerEnterEvent = document.createEvent('Event'); pointerEnterEvent.initEvent('pointerdown', true, true); divRef.current.dispatchEvent(pointerEnterEvent);   //it('"onPress*" events are called when no delay', () => {}); //it('"onPress*" events are called after a delay', () => {}); //});   const pointerLeaveEvent = document.createEvent('Event'); pointerLeaveEvent.initEvent('pointerup', true, true); divRef.current.dispatchEvent(pointerLeaveEvent);   //describe('beyond bounds of hit rect', () => { /** ┌──────────────────┐ *  │  ┌────────────┐  │ *  │  │ VisualRect │  │ *  │  └────────────┘  │ *  │     HitRect      │ *  └──────────────────┘ *                   X   <= Move to X and release */   expect(events).toEqual(['onPressStart', 'onPressEnd']);   //it('"onPress" only is not called when no delay', () => {}); //it('"onPress*" events are not called after a delay', () => {}); //it('"onPress*" events are called when press is released before measure completes', () => {}); //}); //}); describe('nested responders', () => { it('dispatch events in the correct order', () => { let events = []; const ref = React.createRef(); const createEventHandler = msg => () => { events.push(msg); }; const element = ( <Press onPress={createEventHandler('outer: onPress')} onPressChange={createEventHandler('outer: onPressChange')} onPressStart={createEventHandler('outer: onPressStart')} onPressEnd={createEventHandler('outer: onPressEnd')}> <Press onPress={createEventHandler('inner: onPress')} onPressChange={createEventHandler('inner: onPressChange')} onPressStart={createEventHandler('inner: onPressStart')} onPressEnd={createEventHandler('inner: onPressEnd')}>
 </Press> </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(events).toEqual([ 'pointerdown', 'inner: onPressStart', 'inner: onPressChange', 'outer: onPressStart', 'outer: onPressChange', 'pointerup', 'inner: onPressEnd', 'inner: onPressChange', 'inner: onPress', 'outer: onPressEnd', 'outer: onPressChange', 'outer: onPress', ]); events = []; ref.current.dispatchEvent(createKeyboardEvent('keydown', {key: 'Enter'})); // Outer press should not occur as inner press will preventDefault expect(events).toEqual(['keydown', 'inner: onPress']); });  }); });

This issue tracks tasks related to the React DOM implementation of the experimental React Events API () aka React Flare (our internal code-name for the project). The idea is to extend React's event system to include high-level events that allow for consistent cross-device and cross-platform behavior. Note: For now this is completely experimental and won't affect the open source builds of React. [ ] Document specific UX patterns that this enables and fixes. (inc. from my workplace post on styles, Dan & Brian dev tools, apps, etc.) [x] Every user-facing event should have a . Should we provide a standard way to derive data that might be common across events and require different logic for different positional information, e.g., point, delta, offset, etc? [ ] How to test discrete vs continuous events? [ ] Should we polyfill pointer events or not dispatch emulated touch/mouse events in the core, to avoid multiple event components needing to implement the same logic to ignore emulated events? [x] Investigate native pointer capture for retargeting events - This could be particularly useful for drag/swipe UX. [x] Limit all event components to have a single host node as child? If not enforced for all components, we might need this for Hover/Focus/Press at least. FYI [x] Optimize bundle output. [x] Replace magic object export with [x] Document core API for building responders [x] Stop propagation by default but scope to event module types. [x] Investigate ways to listen to root events without first needing to wait for a target event to be dispatched to the event component. [x] Remove from event object passed to callbacks like [x] Ensure discrete events do not unnecessarily force flush previous non-discrete events. [x] Ensure event responder get unmounted correctly and pending events (e.g. long press) properly get removed when doing so. Maybe an unmount lifecycle method needs adding to event responders? [x] Create a new synthetic event and dispatch mechanism that relies on the event being generated in the event responder module, rather than from React. This allows for the event to be better typed and have a much simpler implementation for how React fires the event when dispatched + it means we can avoid pulling in the current SyntheticEvent system and all its dependencies.[ ] Decide on prop name equivalents to RN and .[ ] Determine the potential use cases for DOM and events.

[x] Cross browser and device/modality testing. [x] add functionality [x] Add README [x] Write unit tests [x] disabled [x] onBlur [x] onFocus [x] onFocusChange [x] onFocusVisibleChange to help attach this info to focus/blur events)[x] Cross browser and device/modality testing. [x] Determine event object data.[x] Write unit tests () [x] disabled [x] onHoverMove [x] onHoverChange [x] onHoverStart [x] onHoverEnd [x] delayHoverStart [x] delayHoverEnd [x] ensure doesn't respond to emulated mouse events [x] Add README [x] Add and props. [x] Rename events to , .[x] Cross browser and device/modality testing. [ ] Behaviour for selecting text within pressable. End press on selection event? Add a new props to configure the behaviour, like ? [x] Allow contextMenu to display when element is a link and ctrl is held down during press [x] Cancel long press if active press moves (exceeding threshold, IIRC RN uses 10px delta) [x] Reactivate when moving out-of-bounds press back into the responder region. [x] BUG: press start -move out of target -release -tap press. The second press doesn't cause to be called, even thought those events are dispatched to the core responder system. () [x] FYI: is needed on to prevent browser cancelling after . [x] Prevent contextMenu appearing during a long press on touch screens. [x] Account for UX involving interactions on links with modifier keys held. [x] Add to control when press is released after moving the pointer away from the press target. [x] Add README [x] Always prevent default on <aclicks. Maybe have an override to turn off behaviour? [x] Rename events to , (). [x] Change to (). [x] Change default to 500ms (see note in ) [x] Add keyboard support for all events. [x] Prevent scroll-down page when pressing Spacebar on keyboard to interact [x] Add and props.

[x] Write unit tests () [x] disabled [x] onLongPress [x] onLongPressChange [x] onLongPressShouldCancelPress [x] onPress [x] onPressChange [x] onPressStart [x] onPressEnd [x] delayLongPress [x] delayPressStart [x] delayPressEnd [x] pressRententionOffset / pressRect [x] emulated mouse events [x] ~fix keyboard press events when metaKey is involved~ (this currently works the same way as native, so will leave it for now) [x] any special case anchor tag-related tests [ ] hitslop interactions [x] Determine event object data. Consider adding and (names tbd) to support userland customisation of focus repair. We could return the native elements. A use case to consider: being able to programmatically move focus to an element without allowing keyboards to focus the element (e.g., the document body, the root of a modal). In this case the element (other than a few special cases) must have . [ ] fires when an input element has been changed. This applies to , , and elements with or when is enabled. provides a callback with the event for the element that changed and a of the elment that changed (if a was supplied). [ ] is similar to , but only provides the value changed. This applies to , , and elements with or when is enabled. provides a and of the element that changed (if a was supplied). [ ] for when any elements trigger form submit. [ ] for when any keyboard keys are pressed. [ ] accepts an array of key strings that will get prevented from entering input. [ ] for when any any text selection occurs in any child elements. [ ] fires before a change is about to occur. This applies to , , and elements with or when is enabled. provides a callback with the event for the element that changed and a of the elment that changed (if a was supplied).[ ] Determine event object data (same as Pan) [ ] Cancelling drag. [ ] FYI: is needed on to prevent browser cancelling after . when combining with . [ ] Add README [ ] Cross browser and device/modality testing. [ ] Write unit tests.[ ] Write unit tests. [ ] Cross browser and device/modality testing.

[ ] Cancelling pan. [ ] Add README [ ] FYI: is needed on to prevent browser cancelling after . [ ] Determine event object data.[x] [x] [ ] [ ] [ ] [ ] [ ] scroll directions [ ] Determine event object data FYI [ ] Combine into w/ event data. [ ] Cancelling swipe. [ ] Write comprehensive unit tests. [ ] Cross browser and device/modality testing. [ ] Add README [ ] Determine event object data (same as Pan) [ ] FYI: is needed on to prevent browser cancelling after . Consider whether we need this at all. Some browsers have a native hitslop and we could work with vendors on any potential improvements to the native system [ ] Figure out how to parent of hitslop. [ ] Measurement without reflows (ResizeObserver?) [ ] Add README [x] Figure out solution for SSR w/ non-touch interactions if no client-side JS [x] Add (). [x] Add SSR support[x] Add fields to event components and event targets. [x] Possibly add a or field to event responders? For example the responder module for ReactDOM could have the name . [ ] Expose some DEV only event triggering exports from event responder modules. i.e. [x] Add basic support for rendering event responders and event targets in the tree. Investigate removing object assign polyfill from individual event modules [x] Add internal interactive documentation / fiddle [ ] Investigate press event patterns on , , , etc. [x] Implement high-level components like Pressable (inc delays). [x] Nested Pressables should not bubble events. [x] Investigate accounting for element resizes when determining hit bounds, e.g., using resize observer for notifications
Added some proposed event object data. Suggest forwarding (or creating) the on all events to allow userland customization based on modality that triggered an event; non-standard type to Focus and Press events.
Tracking some regressions I'm uncovering that seem to have been caused by the changes in . is not called when moving within the responder region. Looks like no events are dispatched to the Press module in the bubble phase, which is also breaking the pressRetention functionality. and events are dispatched to the Hover module in the bubble phase (discovered while investigating the Hover runtime error).

In relation to those two regressions: could you add tests for them that fail, but skip them with a comment explaining they need to be fixed, linking to this issue? You don’t need to put them in Press-test or Hover-test, you can make specific isolated tests with them using a custom responder to demonstrate this breaking because of the linked PR (like how we test the onUnmount works). It seems like a bug in the capture/bubbling rather than a specific event responder module.
I got to the bottom of issue (1) and it turns out it's happening because different event modules can influence the propagation of the same synthetic event. In this case, was preventing the propagation of to the root but was listening to on the root.
We could make root events not get affected by target propagation stopping. We can move the target and the root event handling into separate functions, so that this logic handling root events continues to run. Right now, when a target event handle stopsPropagation, the early return skips over too events too. So we'd move this block of code out:
Yeah I played around with modifying that section of code to do just that. But I think you could still end up in situations where 2 different types of event components are listening to the same event defined as a and the inner component is stopping propagation to the outer, e.g., . That's why I mentioned the idea of limiting control over propagation to within event components of the same type, but haven't thought through the implications enough.
Hi guys. Great work! Will React.unstable_createEventComponent support observers api like ResizeObserver and IntersectionObserver?
Event responder modules are free to use whatever DOM APIs they want, so they could definitely use and . We may even need to use them in some of the core responders soon.
Question regarding potential scroll module - have you considered adding smth like property? It's highly useful to know if the scroll was triggered programatically or by user and it's also highly hard to determine this in user space.
What's an example of scroll being programmatically triggered without your knowledge?
I feel like every change to in code is not user introduced.
But that's easy to detect because you're using a programmatic API
It does get a bit difficult when the scrolling trigger is far from the listener, and making them aware of each other introduces fragile coupling. We've had a few such cases in DevTools.

Especially if the focus signal is reactive to some state change.
Here's what I ask: if you have a request please take the time to provide plenty of context. What are the use cases? How are things difficult? How do you imagine a solution might work? etc.
In example showing a "sticker" with a date at the top of the message feed. When a scroll is induced programmatically (or by the browser) then it's distracting to show such thing, but when a user scrolls on their own it makes sense from the UX perspective. Well, it's not a clear way of determining that in onScroll, so some kind of other tracking flags have to be introduced to solve this. It's in general tricky to handle all possible reasons of why scroll has been triggered: it can be caused by wheel (but also wheel doesnt always mean that scroll will happen - u can have other interactions dependant on the wheel), but also you can wheel over inner scrollable element which won't trigger the scroll of the component in question touchmove - but you probably have to calculate this based on some deltas etc keyboard - space, page up, page down, end, home, arrows And those are just things that user can do. Other than that UI might get mutated (even by React, so we can't really track it in userland) and thus trigger scroll event, and as mentioned setting scrollTop also triggers scroll event. And even if u manage to track all reasons of user-induced scrolling it's unobvious when to clear you your flag(s) because you have to consider inertia scrolling etc The solution would be to figure out best heuristics of detecting this. Can't give much detail right now, because this truly is an overcomplicated problem for such a "simple" thing. Web
I don't quite understand the use case you're describing.
Consider another one - a floating "scroll to bottom" button which covers part of the chat feed. We'd like to show such when a user is scrolling on their own (with a delay etc) and hide it after they stop scrolling so we don't cover part of the chat feed constantly. And we i.e. have to work around for situations like mobile keyboard triggering onScroll (cause of the resize etc).

Given the grand retooling happening to the event system here, I would like to re-raise the following request under this umbrella, from TL;DR: listen to / rather than / native events.
Hey guys, looks pretty cool this experimental event system. I wonder if there is still work to do, I would like to contribute to this. I see there are some pending tasks in the checklist but no open issues about them
We're not longer working on this particular approach and will be exploring other ways to work with the DOM event system in the future. We've concluded that the "Flare" event system is too high-level an abstraction and we'd like to explore something that is a bit more familiar to developers familiar with the DOM (e.g., addEventListener) and React's existing tools (e.g., hooks). Our goal is still to make it possible for library authors to work with passive events, capture/bubble phase, custom events, and events occurring on the document from within a React function reducing the amount of event-related code needed in ReactDOM. Ultimately building both intermediate abstractions like the Responder Event system and high-level abstractions like (which we prototyped in Flare) should be possible in user-space.
That's a bummer - this API looked awesome and I had high hopes for it. I guess you have good reasons for not pursuing this, I'm eager to learn with what alternative you will come up with.