Rewrite front-end in JS framework (and back-end as API)

[mnquintana]

Although this is likely a long ways off, we should seriously refactor the entire front-end with Ember, and rewrite the Rails-side of things to be a back-end API. I think we're hitting a point with Reservations where we have Ajaxed a lot of individual pieces of the UX, but it's slowly becoming nightmarish to maintain. Rails + jQuery are not good at managing complex front-end UI interactions that don't require a new page request.

For instance, I'm pretty confident that #718 would be significantly easier to implement if we were using a JS front-end framework. We chose to refresh the entire catalog when making a change 2 years ago because it was a lot easier than trying to figure out exactly what component(s) changed and only updating that/them.

(Why not Angular? Ehhhh wellll, I have a lot of feelings about Angular. We could always talk about it some other time.)

[orenyk]

So do you think that it's worth punting on #718 until this happens? It's not the biggest deal, but it is pretty confusing for patrons.

[mnquintana]

Uhhh probably not worth waiting for this, I was just using it as an example of something that would be easier if we'd had Ember this whole time.

[orenyk]

Ha, fair enough. I'm sure there are lots of examples :)

[squidgetx]

ya i was actually thinking about this myself earlier, I would even consider this a pre-export task depending on what our standards are for pre-export I guess. But seriously rails API + js frontend (I second the motion against angular, though we should consider all our options ie React, backbone, etc.) is really the way to go for future maintainability.

Also we can start right away on converting the back end to an API just adding in the necessary respond_to blocks to return the proper JSON.

If the project had more manpower I would set this actually to the next highest priority after the most pressing bugs mostly because doing this would resolve/render irrelevant like half the currently open issues and make future maintenance a lot smoother. Of course the problem is that we don't really have enough competent rails AND js devs to make it happen on a doable time scale :(

[mnquintana]

I have been learning a lot about various JS frameworks for work, so it's possible I'd be able to get this going over break (I think I'm being waaaay too optimistic about break haha).

@squidgetx I'm still evaluating a lot of JS frameworks for work, but I suspect that React and Backbone are not quite what we're looking for. React is super interesting, but it isn't a full front-end framework the way Ember is - they even bill themselves as just the "View" in MVC (although I know people have built things around it that basically make it the full MVC). It's totally possible that we could use React with Ember / Backbone, although that would probably be overkill. Also, FWIW, Ember is planning on stealing React's best ideas anyway. As for Backbone, I think it's a bit too bare bones, and I think we could easily end up with a similar mess, just without the Rails ERB crap. But this is all still very WIP.

[orenyk]

This sounds like it would be amazing, but "Pre-Export" is set up to package up the current code base for use outside of Yale and such that it's minimally prepared for outside development. I would consider this a major feature (e.g. v4.3.0) but it would be amazing to get it out. I'm still recovering from Hackathonukah but will be reviewing all of this stuff over the next week.

[mnquintana]

I'm realizing now that this would totally break a good portion of our test suite, so we'd need to rewrite a ton of tests.

[orenyk]

Ha, that's a good point. Especially since our integration tests (see #416 and others) all lack JS functionality :-P.

[squidgetx]

Well it would break a large portion of our test suite since it would probably change a lot of how the application works. Half of our controller code is hacks to accommodate a too-complex frontend (I'm looking at you, reservation#checkout and #checkin).

[squidgetx]

Another thing that this would enable is real separation between backend and frontend tasks that would be seriously amazing. It would be a lot easier to imagine what steps would need to be taken to implement a feature and I think that a lot of the murkiness ends up in controller bloat code, since without an API/client structure the controller is the glue between backend/frontend. For instance #516 would simply be reduced to 2 tasks; backend: create one method that takes the cart and outputs a JSON array of associated EMs. frontend: figure out where to call this method and how to display its contents. Honestly think this should be next priority after 4.3.0, though idk how much we will actually be working on the project after that.

[mnquintana]

@squidgetx Totally agree

[orenyk]

Yea, a complete re-architecting of the app would be quite nice :-). We'll see how the semester progresses, maybe we can try to fit this in in our 'free' time :-P.

[mnquintana]

@squidgetx @orenyk Having worked with React now, I've totally changed my mind – I think React is the way to go whenever this re-architecting happens.

[orenyk]

@mnquintana thanks for the update! Do you mind briefly outlining what made you change your mind and things we should look out for if/when this happens?

[mnquintana]

Sure! :smile:

• React has a small, focused API, and it doesn't take that much effort to grok (compared to Angular or Ember)
• React has one concept – Components. You build out a UI by composing Components inside of Components. That's it.
• It's really easy to drop React into an existing app without any serious wonkiness or performance degradation – you can just slowly componentize different pieces of the UI
• Not sure if this is still the case, but React is / was by far the fastest of the big 3 frameworks
• JSX (the questionable looking HTML-in-JS template syntax) is surprisingly intuitive and fun to work with, and allows for the full use of JS in your templates, compared to Handlebars in Ember or Angular's templating which is quite limited
• You don't learn a framework, you learn JS best practices. With other frameworks, you essentially pour time and effort into learning largely non-transferrable skills, which is not awesome considering the incredible rate of churn in JS-land. But since React's API is so small, most of what you write is just plain ol' JS.
• React is the most flexible – it's extremely easy to integrate with other libraries
• Managing state in React just makes so much sense, especially compared to others I've looked at

And more stuff I didn't mention in this article: https://blog.formidable.com/using-react-is-a-business-decision-not-a-technology-choice-63c4641c5f7#.nfjhlmq0a

The downsides?

• If you want to do React the Right Way, it involves configuring a lot of tooling first (but they pretty much all do at this point)
• It has to be paired with a few other libraries for the Full Framework Experience, but that's pretty much a one-time thing that you won't have to worry about again
• It's not totally clear how it's supposed to work with the evolving Web Components spec, despite being "Component"-based