I just started using React on my project this week. It's incredibly easy to use and get running, I'm loving it. It's really simplified my UI development. The UI for my project is something I need to just get done for now, while I build out the rest of the functionality. I'll come back later to make it prettier. But React makes that super easy to do.
Wish I'd talked to the guys at FB about it more before I left.
It's something i've been struggling with quite a bit. Conceptually i love Polymer, and really want to switch, but React's serverside rendering is just hard to beat. I'm scared of showing users page load spinners while my 20 Polymer components all load their data heh
Facebook has been using React in production since 2011. Polymer is a "developer preview", aside from the Material Design presentation, I haven't heard of anything public-facing that Google's actually done with it yet.
React is backwards compatible to IE8. Polymer? Not so much. Unless you live in that mythical world of evergreen browsers, Polymer is sort of just a really great demo.
Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps, which is like wanting steak but eating liver.
I have been trying to use React in an application I am building. One recurring issue I have with React is child to parent component communication. The recommended way seems to be to have the child component emit events which are then caught and handled by the parent component.
Unfortunately, this approach does not work very well in the cases where I have multiple instances of the same component, in which case all the parents will be recieving and handling the event emitted by a single child. I would love to hear any possible solutions for this that do not involve either registering unique event names for each instance of the component or passing in a unique id as part of the event payload, which is then verified by the handler function.
Maybe I'm not understanding the problem correctly, but I simply had the child components 'know' their index or id (stored in props) and then pass that to the parent with any call.
Could you elaborate here on what you mean by "all the parents will be recieving and handling the event emitted by a single child"? Or perhaps post a question on StackOverflow.
What a great site for reading. I'm not usually into design, but reading through that blog forced me into a new appreciation for layout, font, and color.
I planned on using React for my next mobile app project until Polymer was shown off at I/O. React is a fantastic alternative to Angular, but the Paper Elements make Polymer too good to pass up.
I would be over the moon if React had a UI Kit that could be included. We need more app-centric first UI options for rapid development.
Is it only me or does that remind anyone else about basic MVC frameworks, like Backbone used properly?
Oh and don't get me wrong that this pattern gets used again. I can see it being extended here and it looks really nice and promising. I just don't understand the sudden hype.
At Khan Academy most of our frontend is now using React (including our personalized learning dashboard, coach reports, question editor [1], etc.) and we're really happy with it. We have about 750 React components and 50,000 lines of JSX now. We've migrated pieces incrementally and React is really great for doing that because it doesn't try to own your whole app.
My friends and I also just launched Vim Awesome [2], which is not "large" but is completely written in React and is open source if you're curious to look at it.
Our UI for Marathon[1], a framework on top of Apache Mesos, is written in React and uses Backbone models. It uses Require JS for modules and compiling the source into a single file for distribution. The JS root is in the assets directory[2].
There are a few guidelines we have adopted through trial and error so far:
* Use React.addons.classSet[3] liberally. Class name generation becomes simpler for future developers to read.
* Define propTypes[4] for every component. Debugging becomes easier because React gives you informative warnings about mismatched propTypes.
I don't have any open source examples, but I have multiple friends at different mid-size startups who replaced backbone with react and they are all super happy about it.
I'm looking forward to try React myself, but haven't yet.
Seems like React is here to stay and become really really awesome, I haven't heard anybody say bad things about it.
Glimpse v2 is using React/Flux for pretty much everything client related and all parts are open source and on github.
For those who don't know, Glimpse is an OSS diagnostics platform and we are in the process of building out v2 (including NodeJS and .NET backends) - http://getglimpse.com.
The system is quite large. In the end it will contain several major "sub applications" that users can switch between and each "application" has large number of components, major interactions, etc.
We are currently using the following stack:
- Views - ReactJS,
- Server Comms - Superagent + Primus (SocketIO),
- Build - Gulp,
- Packaging components - Webpack,
- Module System - CommonJS,
- Message Bus/Dispatcher - Postal.js,
- Testing - Jasmine, Jest, Chance, Karma, etc
Not enterprise kind-of large, but I'm in the process of building a booking web app (https://zapla.co) using React and Backbone Models/Collections.
I made the decision to switch from Backbone.View to React about ~2 weeks into the project, and so far I'm extremely pleased with it and have not regretted it! Unfortunately, the code isn't open source though.
The majority of the UI for Camlistore is written in React. Unfortunately it's not running anywhere publicly, so you can't play with it. But you could run it locally and poke around.
I've architected two enterprise-class business apps - both projects would have failed without react IMO. Neither are open source, but both use this library for widgets: https://github.com/wingspan/wingspan-forms
At Ruboss, we rewrote Dashcube (https://dashcube.com/) in React, after having performance issues with another JS framework. The rewrite took 4 months, and was totally worth it. We're extremely happy with React...
Wooohoo! Nice release. I especially like the JSX Namespacing! I sometimes found myself sacrificing better organization/naming just so my component rendering code wasn't so hideous.
We still recommend exporting small modules internally in your code base so that things are easier to reason about and dead code elimination can work better -- but when interfacing with third-party libraries, the namespacing feature can be helpful. :)
I seems to me that Mithril is inspired by React, and it's awesome that someone is trying to make things better than React.
That said, I have a bad impression of Mithril, because, in any case, its author should bear some respect to React, as a son to his father. But, instead, he appears very arrogant when talking about React (look here: http://lhorie.github.io/mithril/comparison.html#react) as if it was React that was inspired by Mithril and was reimplement Mithril ideas with worse performance.
That bad impression, caused just by words (and other comments from its author here), pulls me away from Mithril, which is a situation I don't love.
Inline JSX is such a stupid idea, and react.js doubles down on stupid. Why do this? The documentation never explains why it is good to add some invalid JavaScript syntax to a library. I want my templates in the same file as my JavaScript logic, inline no less, peppered throughout variable declarations and function calls all over the place, like I want to stub my toe. I do not want to stub my toe and I don't want to use JSX. Notice the complete lack of support in Webstorm.
Every night when I close my eyes I envision a future in which React surpasses HTML and browsers start to only render REACT code, documents are written and named index.react, amateurish people say they are REACT programmers and everything is so beautiful that you can't stop looking.
_________
Now seriously: there should be a way to turn React from a library to a DSL that could be rendered by any language, so all servers, not only Node, could generate their pages in React and pass them to the browsers.
Event handling could still be javascript, as servers don't need them, but code that rendered elements according to specific this.props should be universal.
[+] [-] HorizonXP|11 years ago|reply
Wish I'd talked to the guys at FB about it more before I left.
[+] [-] fidlefodl|11 years ago|reply
It's something i've been struggling with quite a bit. Conceptually i love Polymer, and really want to switch, but React's serverside rendering is just hard to beat. I'm scared of showing users page load spinners while my 20 Polymer components all load their data heh
[+] [-] joemaller1|11 years ago|reply
React is backwards compatible to IE8. Polymer? Not so much. Unless you live in that mythical world of evergreen browsers, Polymer is sort of just a really great demo.
http://facebook.github.io/react/docs/working-with-the-browse... http://www.polymer-project.org/resources/compatibility.html
[+] [-] morkbot|11 years ago|reply
Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps, which is like wanting steak but eating liver.
See http://jlongster.com/Removing-User-Interface-Complexity,-or-...
[+] [-] arianvanp|11 years ago|reply
[+] [-] swah|11 years ago|reply
[+] [-] bgdam|11 years ago|reply
Unfortunately, this approach does not work very well in the cases where I have multiple instances of the same component, in which case all the parents will be recieving and handling the event emitted by a single child. I would love to hear any possible solutions for this that do not involve either registering unique event names for each instance of the component or passing in a unique id as part of the event payload, which is then verified by the handler function.
[+] [-] insin|11 years ago|reply
http://facebook.github.io/react/tips/communicate-between-com...
[+] [-] theycallmemorty|11 years ago|reply
[+] [-] loganfsmyth|11 years ago|reply
[+] [-] grannyg00se|11 years ago|reply
[+] [-] ChikkaChiChi|11 years ago|reply
I would be over the moon if React had a UI Kit that could be included. We need more app-centric first UI options for rapid development.
[+] [-] planckscnst|11 years ago|reply
[1] http://www.polymer-project.org/components/paper-elements/dem...
[+] [-] yazaddaruvala|11 years ago|reply
[+] [-] megaman821|11 years ago|reply
[+] [-] fattenap|11 years ago|reply
[+] [-] tete|11 years ago|reply
Oh and don't get me wrong that this pattern gets used again. I can see it being extended here and it looks really nice and promising. I just don't understand the sudden hype.
[+] [-] theycallmemorty|11 years ago|reply
React does not ship with any code for saving your data to the server.
[+] [-] islon|11 years ago|reply
[+] [-] asdad|11 years ago|reply
[+] [-] spicyj|11 years ago|reply
My friends and I also just launched Vim Awesome [2], which is not "large" but is completely written in React and is open source if you're curious to look at it.
[1]: https://github.com/Khan/perseus
[2]: http://vimawesome.com/
[+] [-] ssorallen|11 years ago|reply
There are a few guidelines we have adopted through trial and error so far:
* Use React.addons.classSet[3] liberally. Class name generation becomes simpler for future developers to read.
* Define propTypes[4] for every component. Debugging becomes easier because React gives you informative warnings about mismatched propTypes.
[1] https://github.com/mesosphere/marathon
[2] https://github.com/mesosphere/marathon/tree/master/src/main/...
[3] https://facebook.github.io/react/docs/class-name-manipulatio...
[4] https://facebook.github.io/react/docs/reusable-components.ht...
[+] [-] jypepin|11 years ago|reply
I'm looking forward to try React myself, but haven't yet.
Seems like React is here to stay and become really really awesome, I haven't heard anybody say bad things about it.
[+] [-] zbyte64|11 years ago|reply
http://buildicus.com/
I have been distilling all the lessons learned into a lesson plan: https://github.com/zbyte64/reactjs-crashcourse
[+] [-] stevejohnson|11 years ago|reply
It isn't using JSX yet because CoffeeScript integration didn't exist until recently, but it was still a joy to use.
[+] [-] avanderhoorn|11 years ago|reply
For those who don't know, Glimpse is an OSS diagnostics platform and we are in the process of building out v2 (including NodeJS and .NET backends) - http://getglimpse.com.
Current work on the front end can be tracked here - https://github.com/glimpse/glimpse.client/tree/version-2. Very much a work in progress but all good so far.
The system is quite large. In the end it will contain several major "sub applications" that users can switch between and each "application" has large number of components, major interactions, etc.
We are currently using the following stack:
- Views - ReactJS, - Server Comms - Superagent + Primus (SocketIO), - Build - Gulp, - Packaging components - Webpack, - Module System - CommonJS, - Message Bus/Dispatcher - Postal.js, - Testing - Jasmine, Jest, Chance, Karma, etc
[+] [-] Pephers|11 years ago|reply
I made the decision to switch from Backbone.View to React about ~2 weeks into the project, and so far I'm extremely pleased with it and have not regretted it! Unfortunately, the code isn't open source though.
[+] [-] aboodman|11 years ago|reply
www.camlistore.org
https://camlistore.googlesource.com/camlistore/+/master/serv...
[+] [-] fuzzythinker|11 years ago|reply
http://facebook.github.io/react/blog/2014/05/29/one-year-of-...
[+] [-] FreezerburnV|11 years ago|reply
[+] [-] dustingetz|11 years ago|reply
[+] [-] peterarmstrong|11 years ago|reply
[+] [-] hcarvalhoalves|11 years ago|reply
Shorter time to ship, fast UIs and less bugs (because it's easier to reason about state).
[+] [-] strager|11 years ago|reply
[+] [-] presty|11 years ago|reply
but not open source
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] rubiquity|11 years ago|reply
[+] [-] spicyj|11 years ago|reply
[+] [-] Touche|11 years ago|reply
[+] [-] fiatjaf|11 years ago|reply
That said, I have a bad impression of Mithril, because, in any case, its author should bear some respect to React, as a son to his father. But, instead, he appears very arrogant when talking about React (look here: http://lhorie.github.io/mithril/comparison.html#react) as if it was React that was inspired by Mithril and was reimplement Mithril ideas with worse performance.
That bad impression, caused just by words (and other comments from its author here), pulls me away from Mithril, which is a situation I don't love.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] sehr|11 years ago|reply
I get that the creator advertises it here pretty heavily, an that's cool. Doesn't mean everyone else has to as well.
[+] [-] bellerocky|11 years ago|reply
[+] [-] fiatjaf|11 years ago|reply
But you should try writing React templates in pure Coffeescript[1], perhaps reusing your HTML through a tiny tool[2] I wrote for it.
[1]: http://blog.vjeux.com/2013/javascript/react-coffeescript.htm...
[2]: http://html2react.alhur.es/
[+] [-] bellerocky|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] fiatjaf|11 years ago|reply
What is that? No, no, no, stop that! You're becoming Angular!
[+] [-] WickyNilliams|11 years ago|reply
[+] [-] thomasloh|11 years ago|reply
[+] [-] fiatjaf|11 years ago|reply
_________
Now seriously: there should be a way to turn React from a library to a DSL that could be rendered by any language, so all servers, not only Node, could generate their pages in React and pass them to the browsers.
Event handling could still be javascript, as servers don't need them, but code that rendered elements according to specific this.props should be universal.