Ember JS questions

I have been hacking around with Ember and had several questions with issues I have run into.

  1. I have been playing with Ember Data and it seems to work great for reading records. However, the app that I’m considering using ember for would have data deleted from the server pretty regularly. In this case the Ember Data store won’t update with the deleted records so it is showing records that are no longer in the database. I could use something like Faye to push messages to the client that something has been deleted, but I was wondering if there were any other options out there for this.

  2. Let’s say we have an app that acts like Finder. On the left hand side we have ‘Favorites’, ‘Shared’, ‘Tags’ etc. My first thought for doing something like this would be:

var finderRoute = Ember.Route.extend({
    setupController: function() {
        this.controllerFor('favorites').set('model', this.store.find('favorites');
        this.controllerFor('tags').set('model', this.store.find('tags');
        this.controllerFor('shared').set('model', this.store.find('shared');
    }
});
export default finderRoute;

Then in the view I would do something like {{render 'favorites'}} in the sidebar. This seems gross to me but I haven’t figured out a better way to do it (which I’m sure there is).

I don’t know if a lot of people here are using Ember, but I just thought I would post it here to see if we could get a conversation going.

Thanks!

1 Like

I happened to get an hour last week with Igor Terzic, one of the contributors to ember-data, and we asked a question similar to yours. In short, pushing changes to Ember’s store is an exercise left to the reader. A neat feature of the store is that regardless of how the store gets updated – web socket, a client-side polling interval, Ajax adapter, or even commands typed directly in to the console – any views that display affected models will do what you expect. IOW, there’s nothing magical about using one of Ember-data’s adapters to get your Ember application to Just Work.

For your second question, what if you created sub-views for each of your collections – favorites, tags, and shared – and included them into your Finder view? That seems like it might give you better separation of concerns from Ember’s POV. In Ember, views know about their controllers, and controllers know about models, but the reverse is not true. Here’s the relevant guide section that I’m thinking about http://emberjs.com/guides/views/inserting-views-in-templates/. (Could a Favorites view be the same as the InfoView in the example?) I’m pretty new to Ember myself, so this bit is largely speculation on my part.

2 Likes

@Jerry_Busser thanks for your response!

First off did you do AirPair with Igor? If so how was it? I’m thinking about doing AirPair for Ember.

That’s an interesting idea, and I feel like I tried that, but maybe I did something wrong. I’ve been pouring through the source of Discourse, Travis-CI, and the Balanced Dashboard, and I see that very few of those actually use the {{view}} helper, so I think I was trying to avoid doing that, but I could be very wrong.

I realize that my solution definitely didn’t separate concerns, but I was having trouble getting the data I needed into the view. I’ll hack on your suggestion tonight and see what I can come up with!

We did not AirPair with Igor. He put an offer for an hour of free consulting time out on Twitter a couple of weeks ago, and one of my coworkers took him up on it. So we just spent an hour on a Hangout peppering him with questions.

Please let me know how your hacking goes. My company has decided to try Ember on our next project, and so when I saw your question, I decided to research it a bit because I figured we would eventually hit the same problem.

Cool. I’ve been doing some research as well.

As far as setting up a route for multiple models it seems that this might be an agreed upon approach:

var finderRoute = Ember.Route.extend({
  model: function() {
    return Ember.RSVP.hash({
      favorites: this.store.find('favorite'),
      tags: this.store.find('tag'),
      ...
    });
  }
});

export default finderRoute;

If you make the finderController an objectController it will proxy to the names so you could just say favorites rather than model.favorites.

I also found this post on the Ember Forum on a slightly similar thing regarding using {{view} helpers. I was a little hairy on my understanding on {{view}} vs {{render}} and I thought this post explained it perfectly:

Does this match up with your research?

You could check out emberFire. It’s an ember-data adapter for Firebase, so you’d be able to send delete requests from your server and Firebase’s callbacks would automatically update your data. It’s very bleeding edge, however. I ran into a couple problems using it, but I think it’ll be amazing once it’s stable.

I’m definitely not an Ember expert, but I don’t think it’s conventional to look up 3 different models in a single route like that. I think the pattern you’re looking for is to set your finder model to have many favorites, tags and shared instances. Your model method then simply looks up the finder and will return the object with all of its associated favs/tags/whatever.

If you don’t need your finder to be associated to those things, then I believe you can just render each of them inside your finder template. If you have routes that already go out and fetch favorites/tags/shared, you shouldn’t have to repeat yourself inside your finder route.

Hey @James_Fickel, thanks for your input!

I’ve been slightly hesitant to go down the road of using a service like Firebase, but that might end up being the best choice, and perhaps the easiest the implement.

I think my example is a little bit like a dashboard, but is just different because unlike a dashboard the view isn’t taking up the entire screen. I find it strange to create a Ember Data backed Finder object and create the relationships for the sole purpose of displaying them to the screen. These data sets have no relationship otherwise. It seems better to me to create a POJO or a normal Ember Object to back the Finder and then load the data and {{render}} it in the view through the model and setupController hooks.

That being said, I’m an Ember n3wB so I could be off base.