I'm pretty ignorant of this space, please bear with me. You'll notice that the app is written in ES6 and not ES5 (i.e. the > javascript you're likely familiar with). As of React 0.13.x, ES6 with a > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5 syntax) > is the preferred method of writing React apps. For more details on the new > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/ > (babel > is the transpiler used by the demo). >
This sounds very fancy and cutting-edge. Sometimes fancy and cutting-edge things are not ready for prime time. What gives you confidence that this is stable and will not result in trailblazing on our part? -=Bill On Thu, Jul 16, 2015 at 8:50 AM, Joshua Cohen <jco...@twopensource.com> wrote: > For those who are not familiar with React, here's some more details/helpful > links on the underlying technologies. > > 1) You'll notice that the app is written in ES6 and not ES5 (i.e. the > javascript you're likely familiar with). As of React 0.13.x, ES6 with a > transpiler (i.e. a tool to compile the ES6 syntax into vanilla ES5 syntax) > is the preferred method of writing React apps. For more details on the new > ES6 features you can read this: http://babeljs.io/docs/learn-es2015/ > (babel > is the transpiler used by the demo). > > 2) The next thing you'll notice is that the components weirdly intermingle > javascript and HTML. This is a React feature called JSX. JSX lets you > express DOM-like components in a more natural style. You *can* create React > components using pure-JS, but JSX is the recommended way to do so. For more > details on JSX I'd recommend reading: > https://facebook.github.io/react/docs/jsx-in-depth.html. > > 3) With the syntax-strangeness out of the way, the next thing to understand > is React itself. React simplifies building high performance JS apps in a > couple of ways: first, it removes two-way binding, which in complex apps > can make reasoning about what causes what to change and when very > difficult, and second: it provides a virtual DOM. The slowest part of > JS-driven apps is updating the DOM. With React, when your data changes your > components are only re-rendered if they've actually changed; this is > accomplished via the virtual DOM. Components are first rendered into the > virtual DOM and then the new tree is compared against the current one, and > only the portions of the tree that are changed are actually rendered into > the page. For more details about React in general, I'd recommend reading > the React docs themselves: > https://facebook.github.io/react/docs/getting-started.html. > > 4) Finally, the last architectural piece of the demo is Flux. Flux is a > replacement for the traditional MVC model. It provides a unidirectional > data flow for responding to events. Essentially the user interacts with the > app which causes Actions to be sent to the Dispatcher. Stores listen for > events from the Dispatcher and update their state. This causes Views (in > our case React components) to re-render, at which point the cycle begins > anew. You can read more about Flux here: > https://facebook.github.io/flux/docs/overview.html. > > This stuff is relatively new to me as well, so there's a better than zero > chance that there's room for improvement with the way the demo is > implemented. but I think it serves as a good starting point for a > discussion about whether this style of application is palatable. > > Cheers, > > Joshua > > On Wed, Jul 15, 2015 at 6:28 PM, Joshua Cohen <jco...@twopensource.com> > wrote: > > > As mentioned during the IRC meeting earlier this week. I spent some time > > recently putting together a React-driven UI prototype as a strawman for a > > discussion about potentially moving away from Angular for the UI. This > > prototype is now available on Github: > > https://github.com/jcohen/aurora-react. > > > > As mentioned in the README, the project is very simple. It doesn't > > actually talk to the Scheduler and it only contains two pages (of which > > only one attempts to render data). It also uses the current UI layout for > > convenience. The intention to use it as a way to judge whether this style > > of app is preferable to Angular or if we should renew our investment in > the > > current Angular based UI and pay down the tech debt that it has accrued. > > > > Interested to hear everyone's thoughts! > > > > Cheers, > > > > Joshua > > >
