“What parts of this app are the most awkward or thorny?”
- Requiring parens after the decorators for Ember Data attr/hasMany is inconsistent with other Ember decorators; will be nice when those are no longer needed
- I forget why I’m using
.set()andpushObject()on Ember Data models. They might not be required, but if it is, that’s not ideal because inconsistent—it’ll be good when we can use assignment andpush()everywhere. - I ran into an issue where I tried to have a computed property based on an Ember Data ID, but its ID is not tracked, so I needed to use
.get(). This inconsistency was unintuitive. emberjs/data#6393 - I’m always loading core data in routes but saving changes in components. Routes have the store available automatically but components need it injected.
- Having to return RSVP.hash for multiple model calls rather than Promise.all is not ideal; it’d be nice to be on the JS standard. (Not 100% sure if I need to use RSVP.hash, but at some point I understood that I did)
- In component tests, having to call
this.setto make values available to the renderer seems unintuitive. Maybe being able to pass them torender()might make more sense? - Atom and I think even VS Code doesn’t have as great syntax highlighting for angle-bracket components as they do for React JSX and Vue templates. That can’t be a responsibility of the Ember core team; just an observation.
- Having to set up routing actions because I’m using Ember Paper buttons and Items, so I can’t just use LinkTo
- Translating Ember Paper docs to angle bracket syntax can be challenging
- Ember Paper uses separate @value and @onChange arguments; I prefer something that “acts like” two-way binding (so I’m glad Chris Garrett and others are looking into options like box)
- Ember Paper’s @passThru argument is awkward; I think they don’t use splattributes yet, or else I did something wrong while trying to get them working. Splattributes will fix it (but addons set up to work around not having splattributes in the past will need to go through a transition)
- I don’t think this is Ember’s fault, but as components gradually got too big, decomposing them was nontrivial. I had to extricate properties and parts of methods that belonged in one vs. the other. This sounds like the kind of thing that they say React hooks help with, but I haven’t used them enough to know, and I’m certainly not arguing Ember go in that direction. Just an observation.
- Ember-Simple-Auth is an essential add-on for everything I do, and I think it still uses mixins significantly. Would be good for it to be updated to use some approach that is compatible with ES classes.
Let me make an unsolicited point that I really like not having to do any imports in my templates to use application or add-on components. I think the ship has sailed on a new template import syntax for some or all of those? Just an opinion =]