Using Ember to Make the Seemingly Impossible Easy

This session was titled “Using Ember to Make the Seemingly Impossible Easy" with Andre Malan and Heyjin Kim. The talk touched on four different pieces of ember.

The first was migrations. Migrations can be a really difficult issues especially when trying to transfer data from a SQL database to a new database. The speakers told a story about having this problem and trying to solve it. Ultimately, they were able to solve it using ember data. Basically, they did an entire migration based on ember data provided data in both apps which provided them with the mechanism to pull the data out and push it into a different place.

The second aspect they spoke about were visualizations. This is basically helping people understand the story behind the data. In order to do this effectively, they used an ember component (something that was frequently discussed throughout the conference). Basically, in an ember component, they encapsulated D3 code. They did this by defining a components, adding the D3 code into it which allowed them to draw a donut chart. I’d never heard of D3 code before but the main point was that by wrapping this code into an ember component, a developer can change/utilize the ember component to make the changes they need to instead of having to dive into the D3 code.

The third thing they spoke of was infinite scrolling. This was an interesting issue because it involves loading these items into the browser so that they’re essentially ready to go when someone continues scrolling. The speakers specifically spoke about a scrolling list of video events and that for the view to happen, the post view has to go through the vine controller to make the switch to video. Instead, you can swap the DOM from heavy weight to light weight objects and that by constantly clearing out the DOM and repopulating it with new information.

The final thought was on two apps in one. The problem Andre and Heyjin encountered was that they had an app that was entirely behind an authentication wall, but there was one page that they wanted to make a public URL but couldn't because you had to log in to see anything on the site. The solution ended up being a non-authenticated rails app with a new router. Basically, they spun up a new app with a small sprinkle of ember in the controller. If you do this and think about quickly developing different applications then you can send different types of people (ie- consumers, managers, administrators, etc.) to completely different applications leading to different JS structures and views based on what kind of a user the person is.