Question: let ReactDOM; let Press; <del> describe('Press event responder', () => { </del> <ins> const DEFAULT_LONG_PRESS_DELAY = 1000; const createPointerEvent = type => { const event = document.createEvent('Event'); event.initEvent(type, true, true); return event; }; const createKeyboardEvent = (type, data) => { return new KeyboardEvent(type, { bubbles: true, cancelable: true, ...data, }); }; describe('Event responder: Press', () => { </ins> let container; beforeEach(() => {

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.


Question: * real browser event. */ if (typeof window !== 'undefined' && <del> typeof window.dispatchEvent === 'function' && typeof Event === 'function') { </del> <ins> typeof window.dispatchEvent === 'function') { </ins> var fakeNode = document.createElement('react'); ReactErrorUtils.invokeGuardedCallback = function(name, func, a, b) { var boundFunc = func.bind(null, a, b); fakeNode.addEventListener(name, boundFunc, false); <del> fakeNode.dispatchEvent(new Event(name)); </del> <ins> var evt = document.createEvent('Event'); evt.initEvent(name, false, false); fakeNode.dispatchEvent(evt); </ins> fakeNode.removeEventListener(name, boundFunc, false); }; }

I'm still quite new to React, but I guess this is a bug in the React framework introduced in 0.14. Seems like all listeners attached with JSX are broken in native Android browser for Android LTE 4.3, when compiling code with NODEENV development. Everything works fine with NODEENV production compilation. I've tracked it down to being related to ReactErrorUtils, that in development mode do guards on events. The source code: If I simply remove that part of code after compiling the React app, the listeners starts working again. I guess this is not intentional, but instead a bug? To reproduce problem in Android LTE 4.3 (code that works in e.g. Chrome Browser): Using the pre-compiled Getting Started lib
Hm. That's unfortunate. I guess we'll try to find a feature test for this and patch it.


Question: if (typeof window !== "undefined" && window !== null) { headEl = document.getElementsByTagName('head')[0]; <ins> dummyAnchor = document.createElement('a'); </ins> if (window.addEventListener) { window.addEventListener('DOMContentLoaded', runScripts, false);

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: validateChildKeys(arguments[i], type); } <del> var name = type.displayName; if (type.propTypes) { checkPropTypes( name, type.propTypes, element.props, ReactPropTypeLocations.prop ); } if (type.contextTypes) { checkPropTypes( name, type.contextTypes, element._context, ReactPropTypeLocations.context ); </del> <ins> if (type) { var name = type.displayName; if (type.propTypes) { checkPropTypes( name, type.propTypes, element.props, ReactPropTypeLocations.prop ); } if (type.contextTypes) { checkPropTypes( name, type.contextTypes, element._context, ReactPropTypeLocations.context ); } </ins> } return element; },

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: "use strict"; <ins> var CallbackQueue = require('CallbackQueue'); var PooledClass = require('PooledClass'); </ins> var ReactCurrentOwner = require('ReactCurrentOwner'); var ReactPerf = require('ReactPerf'); <ins> var Transaction = require('Transaction'); </ins> var invariant = require('invariant'); <ins> var mixInto = require('mixInto'); </ins> var warning = require('warning'); var dirtyComponents = [];

This throws . Maybe this can be simplified some more but this was the simplest repro I could make. Thanks for sending a repro case over.
Wow, it really was a bug. Narrowed it down a little, but it's still rediculously "complex". Big props to for repro! Anyway, just glancing at the code and from experience, I can safely assume that the issue is that receives multiple updates to the same node from . Which intuitively didn't make any sense at all to me, since always calls when it's done and is basically just recursive. However, when taking another peek at the code, I'm pretty sure that the issue is that (in this case) makes the invalid assumption that all updates belongs to the same root. When that is not the case, an to a component which itself updates another root will only once everything is done. The updates to the other root will NOT after each on that root because will always greater than 0. In practice this means that whenever updates another root, all DOM updates on that root will be batched one after the other (as opposed to batching component updates) which is a violation of assumptions in . It's also very inefficient. Intuitively it seems that what should happen is that all component updates within a call should be (but that is not for sure), exactly how this should be solved in practice I'm not 100% sure right now. But I'm 95% sure that this is what's happening, and the repro does have all the ingredients.
Speaking a bit to in chat, I feel like the issue is that and when called from within become asynchronous as opposed to synchronous as they usually are. Which leads to this issue, but also possibly a lot of other subtle issues.
Apparently is not at all to blame...
Narrowed it down even further, apparently it breaks immediately on the first , the error just didn't show up until later unless prodded.

I still don't feel any more enlightened on the issue though...
Your latest two jsbins (4 & 6) throw different error for me (from in X ): And, if one removes Z from A , the same X throws , because then A render won't have any refs on that render so will be undefined... React docs warn that "Never access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.", don't know if it's relevant here.
Yeah different error, but I'm sure the cause is the same. The issue is the span not actually ever being rendered, just that in the old repro it doesn't actually turn into an error until later.
Ok, so perhaps here's a reduced test case, see console: is being called twice in a row, and the first time the span is not there in DOM even though it has been rendered already. One culprit for this behavior may be that you are effectively calling setState on sibling component where setState would not be allowed on component itself (triggered via componentWillUpdate).
Huh? It does end up being rendered in your test case, and there's no error?
no I didn't want to throw the error so that you can see that the componentDidUpdate will be called double. The point is that first the span is not there and if one would try to access it (as in your ref.getDOMNode()) it would throw. See console for flow.
is defined so it's an error regardless, and more than that, React expects the node to be there, but it isn't and throws an error. Even after it still isn't physically there in the DOM. So something is wrong. Unless I'm missing something.
Yes, there is definitely a problem there as you said, sorry for not being clear. I just wanted to reduce it so that there are no refs or forceUpdates which may bring other problems. One could throw the error in componentDidUpdate for clarity, as the innerHTML is definitely empty where it should not be. But it is interesting that it will be called right away again, and then the span will be there.

But it throws:
Was this fixed?
Was clearing up old some old issues and it seemed like this was fixed, but apparently not.
I've found this same problem. Here's a minimal failing example for React 0.12.2: ,output However, it appears that this is fixed in 0.13RC: ,output. Any ideas which commit fixed this? If there aren't tests which exercise this it might creep back in.
Same here. Was perhaps related? I created a simple test case based on jsbin, which currently passes. Unfortunately I'm unable to run tests in anything besides master so can't really validate.
AFAIK no longer exists as of React 0.13, so this issue should be irrelevant now.


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

Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still).

Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.


Question: // TODO: an explicit expect for no warning? ReactDOM.render(JSXRuntime.jsx(Parent, {}), container); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); if (__DEV__) { JSXDEVRuntime.jsxDEV(Lazy, {}); } else { JSXRuntime.jsx(Lazy, {}); } expect(didCall).toBe(false); }); </ins> });

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.


Question: <ins> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; /*jshint evil:true */ describe('ReactDOMOption', function() { var React; var ReactTestUtils; beforeEach(function() { React = require('React'); ReactTestUtils = require('ReactTestUtils'); }); it('should flatten children to a string', function() { var stub = <option>{1} {'foo'}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1 foo'); }); it('should ignore invalid children types', function() { var stub = <option>{1} <div /> {2}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1  2'); }); it('should warn when passing invalid children', function() { var stub = <option>{1} <div /></option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(1); expect(console.error.calls[0].args[0]).toContain( 'Only strings and numbers are supported as <option> children.' ); }); it('should ignore null/undefined/false children without warning', function() { var stub = <option>{1} {false}{true}{null}{undefined} {2}</option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(0); expect(node.innerHTML).toBe('1  2'); }); }); </ins>

If the contents of the element is constructed in special way, it breaks React on component update with "Unable to find element" error. Here's an example of method body: Here's working jsfiddle (with React 0.12.0): Adding to option props fixes the issue.
React separates the 's children with s. In HTML only text is allowed there and the browser handles it gracefully by removing the s. On the next render React tries to change those s, but can't find them. A workaround is to give a string to the :
Thanks for explaining this. In such case probably the best solution would be to extend error explanation with information about "option" elements (behind "table" etc).
Yea, we should probably do some checks in our ReactDOMOption wrapper and not allow anything but text as children.
Just hit this
This can be fixed by using ReactChildren.forEach in ReactDOMOption to flatten the children before passing it to the raw HTML component. Strings and numbers get concatted together; other elements should be skipped and log a warning for invalid children.


Question: var range = document.selection.createRange().duplicate(); var start, end; <del> if (typeof offsets.end === 'undefined') { </del> <ins> if (offsets.end === undefined) { </ins> start = offsets.start; end = start; } else if (offsets.start > offsets.end) {

Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.


Question: // the amount of time it took to render the entire subtree. var cleanComponents = {}; var writes = measurement.writes; <ins> var hierarchy = measurement.hierarchy; </ins> var dirtyComposites = {}; Object.keys(writes).forEach(function(id) { writes[id].forEach(function(write) { // Root mounting (innerHTML set) is recorded with an ID of '' <del> if (id !== '') { measurement.hierarchy[id].forEach((c) => dirtyComposites[c] = true); </del> <ins> if (id !== '' && hierarchy.hasOwnProperty(id)) { hierarchy[id].forEach((c) => dirtyComposites[c] = true); </ins> } }); });

Calling results in: (this is on a page internally at Facebook so I assume it's a fairly recent React version)
Are you still experiencing this issue internally? If so, can you create an internal task with details and repro steps? Assign to the oncall, cc the React team. Our internal configuration is a bit different, and we don't want to discuss internal code/details/configurations on github. I'm going to close this out, and we can help you debug using internal tools if you're still running into problems.
Small note for anyone experiencing a similar error message who arrived here by Googling: I got bit by this because I updated and without updating at the same time.
I'm getting this issue after upgrading to react 15.0.1. All my React packages (including perf) is 15.0.1. printExclusive() etc. works, but printWasted gives the exception shown above.
Are you running before using it?
Yes. , and the rest of the Perf API works, for example , but not . I changed over to my 0.14.7 branch, and there everything works like it should, and I double checked that both ReactPerf and React was on 15.0.1. ! I can dig around a bit more if this isn't anything known.
Let’s reopen until we hear more.
I had it working for a few minutes and then it started failing without me doing anything strange.
Thanks for the info, do you also have the same stack trace and error message as the first post?
Yes. I was exposing the object as . I tried again exposing it as and it's working again. Puzzling. I'm using the full 15.0.1 ecosystem, on Babel 6, Webpack and Webpack dev server, testing on Chrome.
Any chance you have a public project where you can more or less consistently reproduce this?
Technically this means there was for which there was no . This code is super fragile so it’s hard to pin it down without having a specific component hierarchy that happens to cause this.
If someone wants to spend some effort tracking it down, I would recommend: just before in . just before in . Then please share the relevant logs that correspond to the ID you see in the message.
Thanks Dan, I'll try setting up that to see if I can help.

Unfortunately I cannot share my project right now because of client terms.
Yeah, I thought this might be the case. Thanks for taking the time to investigate.
OK I the lines and I managed to also reproduce the error. . FYI, my app is a SPA, I captured this on a route where I have a long list of items that can be filtered by certain criteria and doing before filtering and after some of those items were removed because of the filtering.
Thank you, this is very helpful! I’ll dig into it and see if I can repro this given the new info.


Question: const type = object.type; switch (type) { <ins> case REACT_ASYNC_MODE_TYPE: </ins> case REACT_CONCURRENT_MODE_TYPE: case REACT_FRAGMENT_TYPE: case REACT_PROFILER_TYPE:

It seems like react-is v16.6 no longer is compatible with React v16.3 - v16.5, in that React v16.3 - v16.5 will use , but 's export will instead be . It seems like the async mode symbol needs to remain the same in react-is 16.6+, and the function would need to check both the AsyncMode and ConcurrentMode symbols.
(Note that this blocks full enzyme support of react v16.6)
Can you explain more about the case in which it’s breaking?
sure - the enzyme react 16 adapter needs to maintain support for all versions of React 16. It provides a "getDisplayNameOfNode" function, which needs to be able to return the string in React 16.3-16.5 (for ), and the string in React 16.6+ (for ). It does this by comparing the to the or symbol exports from . In the 16.3-specific adapter, this isn't an issue, but it does have to lock the version of to (which is the breaking change part) - it should be able to keep working with react v16.3 and 16.anything. If v16.6+ had an symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem.
If react-is v16.6+ had an AsyncMode symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem. I think that sounds okay, we could do it. PR?
Sure, I'll try my hand at it!
This is our mistake because we should have prefixed isAsyncMode with unstable which the actual api was. Or not included it at all. We’re treating unstable effectively as private and will break between minors. Are you ok with not supporting calls that are unstable_ in the future? Because we’ll break them several times between releases and don’t want to keep them all around in bundles.
Prefix or not, renaming things is still going to break consumers. However, I understand react decides to accept this breakage in minor versions. Either way, the value of is that it abstracts over these kind of changes. "Not including it at all" would have meant I had to hardcode this stuff inside enzyme, which defeats the whole purpose of in the first place.

In this case, the bundle size difference is negligible - when this is the case, it seems worth trying to keep back compat, even on things react has decided are effectively private.
The alternative is that we put it behind a feature flag and don’t expose the featur at all. But then it’s much harder for people to try it out for cases where breakages are ok. It’s really hard for people in many environments to use alpha builds.
I understand the dilemma. In this case, the functionality hasn't changed, and I'm not sure why it was renamed - iow i'm not sure how it helps people try it out to have the name change now, when it's still going to have to change again when it gets promoted to being stable. The tradeoffs seem to be somewhere between "difficult for people to try it out", "cause breakage in some amount of downstream tooling", or "incur a tiny additional bundle cost to maintain back compat". It's a tough call, and I'm not asking for a policy change - but in this case, the bundle size increase of seems pretty close to zero (i can't imagine it's more than a handful of bytes), and the benefit is that enzyme (and presumably other downstream tools) will be able to continue using without having to hardcode things.


Question: <del> /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @emails react-core * @jest-environment node */ 'use strict'; let createRenderer; let React; let ReactFeatureFlags; describe('ReactShallowRenderer', () => { beforeEach(() => { ReactFeatureFlags = require('shared/ReactFeatureFlags'); ReactFeatureFlags.warnAboutDeprecatedLifecycles = true; createRenderer = require('react-test-renderer/shallow').createRenderer; React = require('react'); }); afterEach(() => { jest.resetModules(); }); // TODO (RFC #6) Merge this back into ReactShallowRenderer-test once // the 'warnAboutDeprecatedLifecycles' feature flag has been removed. it('should warn if deprecated lifecycles exist', () => { class ComponentWithWarnings extends React.Component { componentWillReceiveProps() {} componentWillMount() {} componentWillUpdate() {} render() { return null; } } const shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<ComponentWithWarnings />), ).toLowPriorityWarnDev( 'Warning: ComponentWithWarnings: componentWillMount() is deprecated and will ' + 'be removed in the next major version.', ); expect(() => shallowRenderer.render(<ComponentWithWarnings />), ).toLowPriorityWarnDev([ 'Warning: ComponentWithWarnings: componentWillReceiveProps() is deprecated ' + 'and will be removed in the next major version.', 'Warning: ComponentWithWarnings: componentWillUpdate() is deprecated and will ' + 'be removed in the next major version.', ]); // Verify no duplicate warnings shallowRenderer.render(<ComponentWithWarnings />); }); describe('react-lifecycles-compat', () => { const polyfill = require('react-lifecycles-compat'); it('should not warn about deprecated cWM/cWRP for polyfilled components', () => { class PolyfilledComponent extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } render() { return null; } } polyfill(PolyfilledComponent); const shallowRenderer = createRenderer(); shallowRenderer.render(<PolyfilledComponent />); }); }); }); </del>

For consideration. These warnings are already covered by renderers based on react-reconciler. Maybe we don't gain that much by mirroring them in the shallow renderer? Maybe it's not worth the complexity? Particularly with more complicated warnings like the ones being for and .


Question:
expect(handler).not.toHaveBeenCalled(); });  it('should not warn when simulating events with extra properties', function() { spyOn(console, 'error'); var CLIENT_X = 100; var Component = React.createClass({ handleClick: function(e) { expect(e.clientX).toBe(CLIENT_X); }, render: function() { return
; }, }); var element = document.createElement('div'); var instance = ReactDOM.render(<Component />, element); ReactTestUtils.Simulate.click( ReactDOM.findDOMNode(instance), {clientX: CLIENT_X} ); expect(console.error.calls.length).toBe(0); });  it('can scry with stateless components involved', function() { var Stateless = () =>

; var SomeComponent = React.createClass({

To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.


Question: --light-color-expand-collapse-toggle: #777d88; --light-color-link: #0000ff; --light-color-modal-background: rgba(255, 255, 255, 0.75); <ins> --light-color-primitive-hook-badge-background: #e5e5e5; --light-color-primitive-hook-badge-text: #5f6673; </ins> --light-color-record-active: #fc3a4b; --light-color-record-hover: #3578e5; --light-color-record-inactive: #0088fa;

I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.


Question: * Listens to window scroll and resize events. We cache scroll values so that * application code can access them without triggering reflows. * <ins> * ViewportMetrics is only used by SyntheticMouse/TouchEvent and only when * pageX/pageY isn't supported (legacy browsers). * </ins> * NOTE: Scroll events do not bubble. * * @see http://www.quirksmode.org/dom/events/scroll.html */ <del> ensureScrollValueMonitoring: function() { if (!isMonitoringScrollValue) { </del> <ins> ensureScrollValueMonitoring: function(){ if (hasEventPageXY === undefined) { hasEventPageXY = document.createEvent && 'pageX' in document.createEvent('MouseEvent'); } if (!hasEventPageXY && !isMonitoringScrollValue) { </ins> var refresh = ViewportMetrics.refreshScrollValues; ReactBrowserEventEmitter.ReactEventListener.monitorScrollValue(refresh); isMonitoringScrollValue = true;

React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.

No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.


Question: if ((props.onLongPress || props.onLongPressChange) && !state.isLongPressed) { const delayLongPress = calculateDelayMS( props.delayLongPress, <del> 0, </del> <ins> 10, </ins> DEFAULT_LONG_PRESS_DELAY_MS, );

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.


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

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens.

~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.


Question: "description": "Basic example of using React with CommonJS", "main": "index.js", "devDependencies": { <del> "envify": "~1.2.1", "react": "~0.10.0", "reactify": "~0.13.1", "browserify": "~3.44.2" </del> <ins> "browserify": "^6.3.3", "envify": "^3.2.0", "react": "^0.12.0", "reactify": "^0.17.1" </ins> }, "scripts": { "build": "browserify --debug --transform reactify index.js > bundle.js"

Hi. In the examples included in the Getting started kit from the version of react defined in in the "basic-commonjs" example is set to 0.10.0. In order for the example to work as expected it should be 0.12.0 Also using Browserify and Reactify to compile fails because of a missing jsx header in I have not tested this in other examples


Question: * `es3` restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility). * The transform for the call spread operator has also been enabled. <ins> ### JSXTransformer #### Breaking Changes * The return value of `transform` now contains `sourceMap` as a JS object already, not an instance of `SourceMapGenerator`. </ins> ### JSX #### Breaking Changes

There seems to have been an API change between React 0.12 and 0.13 that's not covered in the documentation. When using with the option, the source map is now returned as a plain JavaScript object. Previously it would return an instance of and you'd need to call to get the actual source map. Is this an intentional change that just got overlooked when writing the documentation?
That's just an oversight. We aligned JSXTransformer to use the same code as react-tools (as opposed to duplicating efforts with slight variation). This originally changed in react-tools last year - , and then I made JSXTransformer just use react-tools in . I didn't notice that we're doing a bit more post-processing in react-tools. We can add a bit to the changelog for this.


Question: @include code-typography; } <del> div.CodeMirror-linenumber:after { content: '.'; </del> <ins> div.CodeMirror-linenumber { text-align: right; </ins> } .CodeMirror, div.CodeMirror-gutters, div.highlight {

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: onChange={handleFiles} tabIndex={-1} /> <ins> <a ref={downloadRef} className={styles.Input} /> </ins> <Button disabled={isProfiling} onClick={uploadData}

Hi, long time user, first time issuer. I think I found a bug with the Profiler component. When I click on the button at the top nothing happens and there appears to be no new files in my Downloads folder. I think it might be silently failing and that's why I am not getting any response. Has anyone else ran into this issue? Another thing I would like to mention is that I haven't looked through all of the documentation material about the new Profiler. I only read , so if this issue is addressed elsewhere I apologize and also request the source to that solution. Thank you for your time! Versions: *
It seems that this is happening because of the call in the util function. I'll investigate this further.
I fixed the issue. I'll open a PR later today :)


Question: user-select: none; color: var(--color-text); <ins> /* Hide radio buttons for Firefox too */ position:  relative; </ins> /* Electron drag area */ -webkit-app-region: no-drag; }

Website is actually irrelevant, but required. the devtools the settings button. the layout being broken (causing horizontal scrollbar). Screenshot ! Every time No response No response No response No response No response No response
Can you provide some more information? Browser (and version), operating system (and version), DevTools extension version, etc. I can't reproduce this.
Firefox 89, Windows 10, latest extension. It's really not that far-fetched.
I'm not sure why there's hostility in your responses (both to this issue and ). This is a free software product and I'm trying to help you. Providing basic info like browser and operating system version along with a bug report is generally useful, regardless of how far fetched you think the configuration is :smile:
Not sure if this is confirmed by anyone else, but I can reproduce this on Firefox. I'll paste my device information so you can try that out in order to repro. How it looks: ! Machine: Windows 10 Home Browser: Firefox version 89.0.1 (64-bit) Let me know if you need more details, I'll be more than happy to take this up. Update: It also happens on chrome dev tools when you resize your dev tools to some specific width.
If I enable scroll bars on OS X, I can also reproduce this in Firefox. Should be able to fix it then. (Did not have access to a Windows machine to test with.) Edit 1: It looks like this is caused by the tab bar containing too many tabs now (General, Debugging, Components, Profiler, and "x" button). Should be an easy fix. Edit 2: I think the reason for the difference between Firefox and Chrome is that the (supposedly hidden) buttons used for the Tab bar accessibility isn't 0 width for Firefox.
Sorry mate, but I don't understand the question then. You asked for browser & OS, and I gave that exact answer. That's really, honestly, genuinely, everything needed to a repro. I've seen this on every pc running Windows 10 + Firefox so far, which is why it's not that far-fetched. I don't see how that's hostile. And actually, we're trying help each other, aren't we Also how am I responding hostile in ? I'm suggesting a fix. I'm Dutch, so I'm just being direct, not hostile at all. It's my culture, please respect that


Question: // attach another listener to flip the boundary back to its normal state. const thenables: Set<Thenable> = (workInProgress.updateQueue: any); if (thenables === null) { <del> workInProgress.updateQueue = (new Set([thenable]): any); </del> <ins> workInProgress.updateQueue = (new Set(): any); workInProgress.updateQueue.add(thenable); </ins> } else { thenables.add(thenable); }

Do you want to request a feature or report a bug? report a bug What is the current behavior? When using Suspense, I see React.Suspense fallback layout instead of loaded component in IE 11 (IE network panel shows, that bundle was loaded) I can not reproduce this bug in 16.7.0-alpha.2! there is everything ok. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? see the rendered component Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested on IE11 on windows 7 It reproduces only in 16.8.0-alpha.0 I can not reproduce this bug in 16.7.0-alpha.2, there is everything ok. In Chrome is everything ok in all versions.
the problem was with requirements for additional polyfills in newer version
Hmm which ones? I wouldn't expect that.
Could be the same as A reproducing example would be very helpful; that's unexpected.
can you try running this codesandbox and see if it runs on IE11? if not on codesandbox, try to run it locally. thanks!
I tested this in IE11 with as well as and both appear to work correctly. are you possibly using a polyfill? Which Promise polyfill are you using?
IE11 didn't throw any exceptions. So, that I don't know yet, what exactly polyfill do I need. I solved my problem with I can use only the core-js promise polyfill for 16.7.0-alpha.2 and it works. Im using browserstack for IE11. Unfortunately WeakSet polyfill (as recommended) dint't helped. This is the case without bug React 16.7.0-alpha.2 This is the buggy case React 16.7 I will try to find the exact polyfill, but I don't have any ideas yet :).

I runned those examples locally, because they wan't work form sandbox, IE requires more stuff
<img width="1439" alt="screen shot 2019-01-14 at 9 52 58 pm" src="https://user-"
I found matching polyfills after reading and question about Weakmap You need to import not only the Promise, you need to add This is the working version for React 16.7
to clarify, I wasn’t suggesting that you use a polyfill, I was just asking if you were already using one. Just in case it might have been a bad implementation that was causing problems. If you only include the polyfill does it work as expected?
You're right, I just removed WeakSet and it also works.
Thank you for the hint with Sets!
Ah okay, in that case it's expected. React 16 requires both and . This is in the documentation: And in React 16 release notes: That it worked before without is a happy accident. Hope it helps!
It worked because IE11 has native Set implementation, but it isn't compliant. The issue is likely , where we use the API which IE11 doesn't support. maybe we should warn for this?
And how about the Promise ? :)
Ahh. Can you send a PR that just replaces it with an right after creation? I think we didn't want to rely on this.
If you use you need Promise by definition — it depends on you using dynamic which gives you a Promise.
For me, adding the polyfills for , and did not suffice. Instead, this is what worked for me in the :


Question: } /** <ins> * @param {SyntheticEvent} e change event to handle */ function _handleLinkedCheckChange(e) { /*jshint validthis:true */ this.props.checkedLink.requestChange(e.target.checked); } /** </ins> * Provide a linked `value` attribute for controlled forms. You should not use * this outside of the ReactDOM controlled form components. */

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: state.isLongPressed = true; state.longPressTimeout = null; <del> if ( props.onPressChange && props.onLongPressShouldCancelPress && props.onLongPressShouldCancelPress() ) { dispatchPressChangeEvent(false); } </del> if (props.onLongPress) { const longPressEventListener = e => { props.onLongPress(e);

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.


Question: willDeleteListener: function(inst, registrationName) { if (registrationName === ON_CLICK_KEY) { <del> var id = inst._rootNodeID; onClickListeners[id].remove(); delete onClickListeners[id]; </del> <ins> var key = getDictionaryKey(inst); onClickListeners[key].remove(); delete onClickListeners[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!