Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: