aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Cohen <jco...@twopensource.com>
Subject Re: Aurora React UI Demo/Prototype
Date Thu, 16 Jul 2015 20:13:06 GMT
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 <
skarumuri@twitter.com.invalid> 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 <david@dmclaughlin.com>
> 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 <jcohen@twopensource.com>
> > 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 <wfarner@apache.org>
> > 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 <
> jcohen@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 <
> > jcohen@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message