React shouldn't bind wheel or touch events to the document.

[joshduck]

React binds touchmove, touchstart, touchend, touchcancel and wheel handlers to the document. When the user tries to scroll the browser needs to execute these event handlers to ensure event.preventDefault() was not called. This means scrolling will stall while JavaScript is executing.

Chrome has a fast-path that checks whether the coordinate where the touch event happens has touch listeners (https://plus.google.com/+RickByers/posts/cmzrtyBYPQc). If there are no listeners Chrome can allow the scroll to happen even if the main thread is blocked on JavaScript.

We should bind our listeners for these events directly to the node which requires it. That event handler can then dispatch the event to the standard React top level event system. Then it will bubble/capture just like everything else and be visible to all event plugins.

[sophiebits]

This would also definitely fix our initializeTouchEvents problem. I don't know the perf impacts of not bubbling to document though.

[zpao]

[SanderSpies]

Anyone picking this one up? Otherwise, I would like to give it a go :-).

[possibilities]

It would also fix the problem I'm having here:

http://jsfiddle.net/BSJPd/1/

Arguably not a bug but unexpected and undesirable for me.

[petehunt]

@SanderSpies you're exactly who I had in mind for this! :)

[SanderSpies]

petehunt: great :)

Potential scenario's I'm seeing:

• elements with listeners at the same level.

So for these event types there will be more then one event listener

• child element listens to same event as parent element.

I guess we always want to use the parent element

• during lifetime the dom changes, and therefore also the element which needs to listen.

Which would imply we would also need to remove/add event listeners on the fly, not sure if we already do that

I'm thinking of adding something like 'bindLocally' at the event plugins level like:

onTouchMove: {
bindLocally: true,
phasedRegistrationNames: {
bubbled: keyOf({onDragOver: true}),
captured: keyOf({onDragOverCapture: true})
}
}

Good idea? Bad idea? Missing stuff here?

[sophiebits]

It's really a function of the topLevelType topTouchMove, not the event that you wrote there. For naming, delegate: false might be clearer.

Right now I don't believe we ever remove listeners.

[SanderSpies]

@spicyj I wrote that code a bit too hastily I guess. Should have been touchMove, also notice the onDragOver + onDragOverCapture that I forgot to correct...

[SanderSpies]

Currently the event listeners are attached before React inserts the nodes into the DOM. So I was wondering how I should handle this.

I was thinking of letting ReactEventEmitter.listenTo create a 'bag' for local events, that is later used by a new function (addLocalEventListeners?) which is called by ReactComponent._mountComponentIntoNode.

Thoughts on this?

[sophiebits]

Are you sure it's before the DOM nodes are created? Regardless, probably you want to tie it to the transaction -- you can see how ReactReconcileTransaction stores a queue of componentDidMount callbacks (ON_DOM_READY_QUEUEING/ReactMountReady) and a queue of listeners to put (PUT_LISTENER_QUEUEING/ReactPutListenerQueue). If the put listener queue can't easily be modified to do what you want (though I'm guessing it can), you can make a new transaction wrapper and add it to the list there.

[u9520107]

Is this still being investigated?
In my project, I have a component that uses scrollable div's with roughly 300 direct child, which nests maybe 6 to 7 children. While putting translateZ(0) to force composition layer seems to be able to boost scroll performance to 60 fps. As soon as the document wheel event is attached, the performance is crippled. Even after the component that relies on wheel events is dismounted, the wheel listener on document would live on, reducing the scroll performance to around 30-40 fps.