Wishlist: ability to disable the synthetic event system

[jaredly]

Would there be huge problems caused by optionally disabling the synthetic event system? I'd like the option to do so in order to get more responsiveness out of underpowered machines.

[sophiebits]

Not quite sure what you mean. If you don't attach any events to your elements then there shouldn't be any overhead from the events system.

[jordwalke]

@jaredly, are you seeing issues? The Synthetic event system may actually help you get responsiveness out of underpowered machines. Attaching event listeners to actual DOM nodes is expensive.

[jaredly]

Yeah, I'm seeing a lag with my <input>s. I know I can just hack around it with componentDidMount, but I wondered if it would be possible to just switch to native event handling.

[sophiebits]

@jaredly You're seeing lag that goes away when you use native event handling? I'd be interested in seeing a test case that shows that.

[jaredly]

step 1) use a really underpowered netbook :)
yeah, I'll put together a test page

[jaredly]

The problem is probably exacerbated by the "keydown -> change state -> re-render -> update dom" loop for bound input elements.

[jordwalke]

Is this just an input related problem? Or do you see issues with click handlers (I suspect you don't)?

[jaredly]

I've only noticed it on the inputs

[jaredly]

I don't have any onMouseMove handlers at the moment, but I wouldn't be surprised if it had issues as well

[jaredly]

click handlers don't generate enough events to bottleneck

[plievone]

@jaredly There is also an issue #1178 on inputs.

[syranide]

@jaredly It sounds like your problem is large parts or the entire app re-rendering (without any shouldComponentUpdate) and it's simply too costly and ends up slowing down the input.

[jaredly]

That's what I thought, but having a single input on a page with nothing
else and it was noticeably laggy as compared with a non react input (on my
rather underpowered netbook)
On May 18, 2014 9:02 AM, "Andreas Svensson" notifications@github.com
wrote:

@jaredly https://github.com/jaredly It sounds like your problem is
large parts or the entire app re-rendering (without any
shouldComponentUpdate) and it's simply too costly and ends up slowing down
the input.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1269#issuecomment-43443595
.

[sophiebits]

No plans to do this.

[tusharmath]

I am trying to build a side nav that can be dragged in from the left. I listen to the touchmove event on the screen and as the thumb slides right I keep calculating translateX and push it to the state, which can be then used to render the sidenav. The problem that I have is —

The touchmove event is fired at a very high speed, though I throttle these events using requestAnimationFrame while calculating translateX, these synthetic events that even though are not being consumed take up valuable ms from the frame.