I actually checked into a React replacement for smart-table, and one does exist: https://github.com/zippyui/react-datagrid.
On Thu, Jul 16, 2015 at 3:05 PM, Suman Karumuri < [email protected]> wrote: > Thanks for building this Joshua! > > I am -1 on a proposal to switch FE technology stacks for the same reasons > David mentioned. > > Also, the current scheduler UI uses an angularJS library called smart table > for rendering tables, searching and sorting columns and pagination. Since > there is no react equivalent of the same library, we have to re-implement > the library in react, which could potentially mean we will end up > maintaining a lot more code if we moved to react. > > On Thu, Jul 16, 2015 at 11:24 AM, David McLaughlin <[email protected]> > wrote: > > > Thanks for doing this and sharing code! > > > > I'd be -1 to any proposal to switch our FE technology stack for several > > reasons. > > > > I find this stack way too advanced for what the scheduler UI currently > > does. This is also a problem with Angular, but we're already stuck with > > that now. > > > > I also don't think any of the problems with the current UI are due to > > Angular. The biggest hole that I see in our FE code is lack of automated > > testing, and this technology stack doesn't change the trade-offs involved > > in solving that. > > > > I also don't think our current technology stack hinders our ability to > > resolve any of the currently open UI tickets, nor does it prevent us from > > doing any of the 'this would be cool' features we've talked about. The > > biggest barriers are more about abstractions or lack of concrete > interfaces > > between the components in Aurora. > > > > I think we need to acknowledge that for the most part the Aurora project > > does not have a great deal of FE resource. Switching stacks again would > > involve retraining everyone to this new thing, but based on the nature of > > the code in the demo - it also involves making sure everyone has cutting > > edge knowledge of JS, which would be a new barrier to entry for anyone > > looking to make quick UI fixes and also make code reviews much harder. I > > think for an infrastructure product like this where most of the expertise > > is in server-side development, it's probably safer to be a couple of > > iterations behind the latest fads in the JS community. > > > > > > Cheers, > > David > > > > > > On Thu, Jul 16, 2015 at 11:07 AM, Joshua Cohen <[email protected]> > > wrote: > > > > > There are numerous large and stable sites powered by this technology. > Not > > > least among them are Facebook and Instagram for which these > technologies > > > were developed (that being React/Flux). ES6 being transpiled down to > ES5 > > is > > > widely adopted as well (off the top of my head, I know Slack does it). > > ES6 > > > is an officially adopted standard and direct browser support for it is > > > increasing quickly: https://kangax.github.io/compat-table/es6/. As you > > can > > > see from the table Firefox and Chrome have already implemented > > significant > > > parts of the spec. Predictably IE and Safari are lagging behind, but I > > > think we're past the point where we need to be concerned about ES6 > never > > > being adopted. Transpiling in general is a common practice in the JS > > > community as can be seen by the popularity of things like CoffeeScript. > > Of > > > all the technologies that would potentially be introduced by this > change, > > > using ES6 syntax and transpiling it to ES5 is the one that I have the > > least > > > qualms about. > > > > > > On Thu, Jul 16, 2015 at 12:53 PM, Bill Farner <[email protected]> > > wrote: > > > > > > > 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 < > [email protected] > > > > > > > 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 < > > [email protected] > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
