4 ms·

React contributor here. The bit about removing event handling abstraction doesn't make much sense. 1. Since React's event handling is also virtual (just like i

React contributor here. The bit about removing event handling abstraction doesn't make much sense. 1. Since React's event handling is also virtual (just like its DOM), cross-browser inconsistencies are taken care of for you. Sure, you could always attach your native events after mounting a component, but unless you're using jQuery or something with very good cross-browser support, you're bound to trip over the same browser bugs we already solved (IE8+!). 2. The virtual event system is super performant. It does event delegation for free. Internally, it's implemented as one single event handler at the top; no need to worry about whether you should put a click event on the list items, or on the list itself anymore. Events are also pooled. 3. Since the system's virtual, it opens doors to custom event plugins, i.e.: <div onTapHold={bla} /> In fact, React's mobile tap event is a custom plugin. Removes the 400ms delay. You get the point.

evmar 13y ago
(I'm the post author.) Thanks for reading and commenting! As I mentioned in the footnote, for my purposes (an app where I am likely to be the only user) I don't care about IE8 support, so it's kind of a bummer that I have to ship support for it. (In my day job I use Google's Closure library which has the same problem -- lots of additional complexity to work around IE bugs. I appreciate that removing this support isn't as simple as just compiling it out, too.) Similarly for the 300ms delay: the delay is gone on current Chrome on mobile (when you're using width=device-width; I only know this because I used to work on Chrome), which is the mobile browser I use. Another way of saying this is that React is a combination of the virtual DOM stuff and a bunch of other "useful webapp stuff" like making events work across browsers and installing event listeners on the root element etc. I appreciate for you and the React authors' purposes those are the same problem and difficult to disentangle, but all I wanted to use was the virtual DOM part. (I guess the analogue would be like thinking Rails's ActionDispatch library is neat but then discovering you had to use their code-generation scripts and ORM library as well. Sorry if that metaphor failed, I'm not so knowledgeable about Rails.) Anyway, since I'm mostly just tinkering with React etc. the size thing doesn't matter so much, which is why I put the comment way down in a footnote. But the whole "you must swallow the whole thing at once" thing is also the reason I've never looked into Ember or whichever other comparable framework. Maybe at some point, as a continued learning exercise, I'll attempt to reimplement the subset of React that I actually use to better understand the design space you already know.
- peterhunt 13y ago
  Hey, another React team member here. Yes, some compatibility code exists, but it's mostly just part of the default config which you can change. Additionally we don't inject things like the tap plugin by default so you aren't getting those extra bytes. You can see what I mean about React's modularity by looking at this file https://github.com/facebook/react/blob/master/src/browser/ReactDefaultInjection.js https://github.com/facebook/react/blob/master/src/browser/Re...
- vjeux 13y ago
  Removing event management from React core is a common request but it wouldn't really be a wise decision. 1. Need a way to manage events: All the applications are handling events in one way or another. So you've got to have a way to implement event handling in a React application. 2. Cannot use existing event libraries: Because React manages its own Virtual DOM and has a very declarative nature, it is not easy to use raw DOM imperative APIs in other to implement event handling. Therefore, you cannot just plug in any event handling library, you've got to have one that works on-top of the Virtual DOM abstraction. 3. Performance is a requirement: The way you code in React is by describing the way you want the DOM to look like at all time. If not implemented properly, the performance is extremely bad. The fact that we implement global event delegation is not just a bonus, for some of our apps adding/removing event listeners is actually the bottleneck. 4. Bonuses: Having compatibility for IE8 and custom event plugins is actually the cherry on-top of the cake. Since React has its own event management, supporting those is pretty trivial and isn't a big amount of code. We worked very hard so that React core is extremely small and doesn't contain "other useful webapp stuff". We have a special addons section for that: http://facebook.github.io/react/docs/addons.html http://facebook.github.io/react/docs/addons.html

evmar 13y ago

(I'm the post author.) Thanks for reading and commenting! As I mentioned in the footnote, for my purposes (an app where I am likely to be the only user) I don't care about IE8 support, so it's kind of a bummer that I have to ship support for it. (In my day job I use Google's Closure library which has the same problem -- lots of additional complexity to work around IE bugs. I appreciate that removing this support isn't as simple as just compiling it out, too.) Similarly for the 300ms delay: the delay is gone on current Chrome on mobile (when you're using width=device-width; I only know this because I used to work on Chrome), which is the mobile browser I use. Another way of saying this is that React is a combination of the virtual DOM stuff and a bunch of other "useful webapp stuff" like making events work across browsers and installing event listeners on the root element etc. I appreciate for you and the React authors' purposes those are the same problem and difficult to disentangle, but all I wanted to use was the virtual DOM part. (I guess the analogue would be like thinking Rails's ActionDispatch library is neat but then discovering you had to use their code-generation scripts and ORM library as well. Sorry if that metaphor failed, I'm not so knowledgeable about Rails.) Anyway, since I'm mostly just tinkering with React etc. the size thing doesn't matter so much, which is why I put the comment way down in a footnote. But the whole "you must swallow the whole thing at once" thing is also the reason I've never looked into Ember or whichever other comparable framework. Maybe at some point, as a continued learning exercise, I'll attempt to reimplement the subset of React that I actually use to better understand the design space you already know.

peterhunt 13y ago
Hey, another React team member here. Yes, some compatibility code exists, but it's mostly just part of the default config which you can change. Additionally we don't inject things like the tap plugin by default so you aren't getting those extra bytes. You can see what I mean about React's modularity by looking at this file https://github.com/facebook/react/blob/master/src/browser/ReactDefaultInjection.js https://github.com/facebook/react/blob/master/src/browser/Re...
vjeux 13y ago
Removing event management from React core is a common request but it wouldn't really be a wise decision. 1. Need a way to manage events: All the applications are handling events in one way or another. So you've got to have a way to implement event handling in a React application. 2. Cannot use existing event libraries: Because React manages its own Virtual DOM and has a very declarative nature, it is not easy to use raw DOM imperative APIs in other to implement event handling. Therefore, you cannot just plug in any event handling library, you've got to have one that works on-top of the Virtual DOM abstraction. 3. Performance is a requirement: The way you code in React is by describing the way you want the DOM to look like at all time. If not implemented properly, the performance is extremely bad. The fact that we implement global event delegation is not just a bonus, for some of our apps adding/removing event listeners is actually the bottleneck. 4. Bonuses: Having compatibility for IE8 and custom event plugins is actually the cherry on-top of the cake. Since React has its own event management, supporting those is pretty trivial and isn't a big amount of code. We worked very hard so that React core is extremely small and doesn't contain "other useful webapp stuff". We have a special addons section for that: http://facebook.github.io/react/docs/addons.html http://facebook.github.io/react/docs/addons.html