Hacker News Reader

Comment by chrishenn | Hacker News Reader

I've been working with Ember over the past few months and am still impressed with how simple and productive it makes every day tasks. Basic CRUD stuff, especially render code, is a lot less drudge work. I'm even more excited for where the community is leading the framework, through projects like ember-cli and htmlbars.

Ember is conceptually pretty massive though. A tutorial like Michael Hartl's Rails tutorial would be a huge benefit, it looks like that's what this is aiming for. Thanks!

View on HN

On the other hand, I've found many things lacking in Ember.js, though most of my gripes are with ember-data, so I don't know if you're thinking of that as part of Ember.js.

A couple of examples of Ember.js-specific gripes though:

- We have a table with one of the filters just stops working after changing the value 4 ~ 5 times. I've dug into this, but I can't really figure it out without going into the Ember.js internals (which I have done before, but the time sink isn't currently worth it). I've boiled it down to the fact that at some point Ember.js stops responding to changes on a particular attribute. Computed properties stop working sooner, but even a .observes('attribute') stops triggering after 5 or 6 changes.

I get that software is not bug-free, but how am I supposed to even debug something like that? It would be fairly difficult (and time-consuming) to boil it down to a simple test case, as this is the only place we're seeing this happen and it's in a large Ember.js application.

- There is no case/switch statement in Handlebars. I'm left with deeply nested if/unless blocks, or tons of computed properties on controllers/views that generate this stuff. E.g.:

  {{#if valueLoading}}
    Loading...
  {{else}}
    {{#if valueLoadingFailed}}
      Error!
    {{else}}
      {{#if value.length}}
        <ul>
        {{#each item in value}}
          <li> {{item}} </li>
        {{/each}}
        </ul>
      {{else}}
        No Items.
      {{/if}}
    {{/if}}
  {{/if}}

vs.

  {{#if value.length}}
    <ul>
    {{#each item in value}}
      <li> {{item}} </li>
    {{/each}}
    </ul>
  {{else}}
    {{stateMessage}}
  {{/if}}

  ... and on the controller ...

  stateMessage: function () {
    return this.get('valueLoading') ? 'Loading...'
         : this.get('valueLoadingFailed') ? 'Error!'
         : this.get('value.length') === 0 ? 'No Items.'
         : '';
  }.property('valueLoading', 'valueLoadingFailed', 'value.length'),

1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad.

2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.

> 1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad.

This was a single value (e.g. 'selectedItem') populated by a Ember.Select view/component. After changing the selection a number of times, all things watching 'selectedItem' completely stop firing off (until a page refresh). No idea why.

There is going to be some future work on some of the form elements. They're really not quite where they need to be.

I hope it works out for you but that's just about exactly how I felt immediately before I realized it was not going to work for a very large project, switched to Angular and haven't looked back since. There was no comparison at all for me between Ember and Angular but everyone's needs are different.

What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.

Ember's examples on their site are always the simplest use-case. For example, find me an example on their site of saving a complex relationship that was newly created by your application. Let's take the example of an invoice. Let's say you have an Invoice model, and an InvoiceLineItem model in a one-to-many relationship.

How do I save the creation of a new invoice (with line items) as a single transaction? As far as I can tell, you can't without breaking from Ember Data's very strict 'this is the way things should be done' model.

You have to create a new Invoice, then create the InvoiceLineItems doing something like this:

  var self = this;
  self.get('store').createRecord('invoice', {
    .. attributes ..
  }).save().then(function (invoice) {
    return Ember.RSVP.all(self.get('lineItems').map(function (item) {
       return self.get('store').createRecord('invoiceLineItem', {
           invoice: invoice,
           .. attributes ..
       }).save();
    });
  }).then(function (invoiceLineItems) {
    // do something
  }).then(null, function (error) {
    console.error(error);
  });

Note that this isn't even taking into account how to rollback INSERTs if, for instance a single invoiceLineItem fails to be created.

The 'other' way to do it is to create just an Invoice model, and have a lineItems attribute of type 'raw' and just create a RawTransform that's just as pass-through of whatever the JSON has for that attribute. It works, but at the same time, feels like it's going against the Ember Data Way, especially if you have a need for an InvoiceLineItem to be its own model (i.e. to be able to maintain relationships to other things and look one up by ID via the API).

Then you might have something like:

- Invoice and InvoiceLineItem models

- A RawTransform:

  App.RawTransform = DS.Transform.extend({
      deserialize: function (data) { return data; },
      serialize:   function (data) { return data; },
  });

- An attribute like so (on Invoice model):

  lineItems: DS.attr('raw'),

- Code that looks like this:

  var self = this;
  self.get('store').find('invoice', invoiceId).then(function (invoice) {
    self.get('store').pushPayload('invoiceLineItem', { invoiceLineItems: invoice.get('lineItems') });
  });

If your API supports it you can use the EmbeddedRecordsMixin[0]. In general though, what would be a sane default for handling multiple REST API calls to single-model endpoints?

[0]: http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin....

I really wish there was some thorough examples of using Ember + Ember-Data. Ideally it would be backend agnostic (mocked client side xmlhttprequest) and go from doing simple things like saving a model all the way to doing more complex things like you showed.

Drupal for instance has a /really/ great project that maintains a bunch of thorough examples (https://drupal.org/project/examples) which were indispensable when I did Drupal a while back.

There really should be better examples. In the mean time, you should check out the Balanced Dashboard, I've learned a good amount from it

https://github.com/balanced/balanced-dashboard

It's kind of funny, but I don't even remember simple things being spelled out. For example, in their use cases all of the models and routes are single words like: post, comment, todo, etc.

In some places, you see 'Post' and others 'post', but there is nothing explicitly spelling out how that works for multi-word items (e.g. MultiWord => multiWord). Same with underscores in route names (e.g. route name 'multi_word.item.index' => MultiWordItemIndexRoute).

Yeah, the magic rejiggering of names everywhere with no clear documentation of what mapped to what† killed my interest in Ember the first time I tried to actually use it for even a fairly simple app.

† Plus the enforced snakeCase/CamelCase everywhere, but that's more to do with me far preferring names_with_underscores in general.

This is one of the reasons that Ember.js + Rails seems like the preferred setup. Ember.js + Python gets you into converting underscored names to camelcase names.

http://emberjs.com/guides/concepts/naming-conventions/ ?

That's a good generic overview but doesn't hit how the code handles the edge-cases.

Maybe to clear some confussion, snake case is exactly naming_things_with_underscores.

And SCREAMING_SNAKE_CASE, one of my favourite names for a convention ever, is when snake case is in all caps ;)

Replying to the sibling. There was documentation of how the names changed - you just need to know where to look:

https://github.com/emberjs/data/blob/master/TRANSITION.md

I'm not talking about transitioning from 'old' Ember Data to 'new' Ember Data. I'm talking about someone completely new to Ember looking through the examples and documentation. Even if they were looking through the repository, it would be easy to overload a file called "TRANSITION.md" if you don't need to transition from an older Ember Data version.

> Ember's examples on their site are always the simplest use-case.

This is really key. Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`. Obviously, this is the page that displays info about episode 2 of season 3 of the TV show with id 555. So how do I reference the tv_show model (which I will almost certainly need to do) from the `EpisodesIndexController` or the `episodes/index` template? Do I really have to specify `needs` [0] on every controller nested under `TvShowsController`, and perhaps add a `setupController` hook to make the property easily accessible like in this tutorial [1]?

Granted, I'm pretty new to this, so maybe I'm just missing the obvious way to do this sort of thing clearly.

[0] http://emberjs.com/guides/controllers/dependencies-between-c...

[1] http://balinterdi.com/2014/02/26/a-common-resource-route-pat...

> Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`.

http://emberjs.com/guides/routing/defining-your-routes/#toc_... ?

These are the first three results for "Ember nested routes" on Google. They're all pretty simple and straightforward. Hope that helps!

Perhaps my wording wasn't great, but I'm talking about the specific issue that I explain later in the paragraph.

Ah, my apologies! I am also learning Ember, so I am not entirely sure. Hopefully someone else can come along and enlighten both of us.

I have a large, complex Ember.js + Ember-Data + Flask API app, and I don't think that I use `needs` anywhere in the codebase, so I don't think it's absolutely necessary. IIRC, the documentation says that `needs` only applies to singleton controllers. If you have a controller associated with a model (vs. a view + controller + route combo), I would assume that it's not a singleton (i.e. controllers associated with a view are singletons in that Controller.init() is only called once, even when switching away and back to a view).

To use my example of an app with URLs like "/tv_shows/555/seasons/3/episodes/2", if you're in the episodes/index controller (or template or view), how do you reference the particular season and tv_show that episode is part of?

Reply on news.ycombinator.com