I don’t want to lock this thread, but this thread seriously has just devolved into a dumping ground for people that have probably spent 0 time reading the docs or seeking help. The number of complaints in here for “how do I” that would have been solved within a minute of googling / docs reading is absurdly large, and only makes people think there is a problem where there isn’t.
But the reality is, stackoverflow (and every similar website) is filled with the “why do you want to do this?” responses for every langauge/framework combination out there, not just Ember. If people can do that with things from PL\SQL, Java, PHP, Python, Angular, HTML, etc… then their is no reason to believe that the same thing will never happen in Ember.
I dive in and answer questions on Slack and SO more than most, and I ask this question a lot, not because I disapprove of their doing something, but because context for a question very very much matters. 99 times out of 100 I ask that question, it turns out the person has turned something very simple into something overly complex by overthinking a problem they don’t have. There aren’t very many hard problems in Ember, so when someone thinks there is, I tend to need to figure out what it is they actually want to accomplish in order to show them how to do it.
Not compared to many others, so especially if you’re on the slack channel, you always see the same couple of people.
Our active engagement on Slack is actually very very high, but several of the admins (myself and Locks) intentionally make ourselves available for much of our day to answer questions, and many of Ember’s core team members also frequent Slack (such as rwjblue) in order to keep the entire community available to everyone.
I’ll be willing to do that when Ember stops advertising Ember Data and takes it off its guides and API docs. Being honest about Ember Data
We all have issues with ED, but if we did this it would never improve. It’s still the best data layer out there, and getting to be more so entirely because myself and lot of others actively point out flaws and suggest alternative approaches. Over time, those flaws and approaches get coalesced into a working solution. ED is down to just a few flaws (and some more visible docs on the attrs
feature) keeping it from being a very robust and edge-case tolerant data layer.
The reason I don’t recommend anyone look at other data layers anymore, is because there isn’t another one that’s nearly as good. Ember-orbit fizzled, the devs I know using pouch have had to do most of their own maintenance there, ember-model is unmaintained, ember-simple-model/simple-store is not feature complete enough for most apps, falcor is new and largely untested, redux has it’s own issues with performance and immutability and doesn’t solve any of the problems ED has remaining either.
Try to understand what the person is trying to communicate, and how it fits in with Ember concepts. Obviously, this can be difficult if said concepts are already hazy, but you’re probably staring at a strong hint. Hit the docs again.
This is a VERY good point. One of the things the Ember community really has going for it is a level of politeness, maturity, and willingness to help anyone (even the most basic of beginners) find their path to being an expert. It’s (usually) not likely for a reply to be snide, we just need to find the right question to answer. (I’m human though, and sometimes I’ve had a bad day, and sometimes I’m a little snide, and when I am, I apologize and then stop answering new questions until I’ve had more coffee and a snack).
Please don’t pretend you know every use case. The person asking the question may have very legitimate reasons for doing things they way they do it, reasons you couldn’t possibly know when you haven’t seen the project in its entirety. Sometimes the only reason for this is that “it would take too much time to change this right now” and this is a perfect valid reason for anyone living with time constraints and having a hard time getting the fundamental concepts right.
We don’t, in that 1/100 case that this is true, I help them find the answer for how to do this the hackish way that will work for them. I then table that hackish way for helping others in the future, and use it to suggest to core new APIs that should be public to make this thing easier to accomplish in the future. We (the people usually answering questions on Slack) just don’t start with the hackish way, because it’s that hackish way that prevents you from easily upgrading ember, or gives you maintenance headaches, or induces bad performance in your app.
Ember’s community is too small for that to happen, at least at the moment.
I don’t think that’s true at all anymore.
If you have a non-standard API, you’re kind of out of luck for example. Yes, there are ways to get it to work, but it’s completely not obvious how to do so and may require substantial reading of the source code.
Absolutely, and I’m working with some others and I’ve been reaching out to ED devs to encourage improvement here, find me on slack (@runspired) and I can point to you some of the ways you can easily throw a layer in front of ED now to make it play nice. We need a few more cowpaths before we can build a good solution that solves edge cases, and it’s likely going to be an addon with an alternated ED interface and an alternate adapter/serializer layer to enable that.
the 20% of the time that you need to do something different, it ranges from extremely painful to near-impossible.
I felt this way in Ember several years ago, but once I learned the primitives a bit more I realized that 99% of that 20% I’d been getting in my own way. While Ember has a lot of areas in which it needs to improve, there aren’t many things that it actually makes painful to near-impossible. This, I think, is where the guides actually fall short. They don’t do a great job explaining concepts that are mid-to-high level.
I’m yet to upgrade to 2.x since I have add-ons that rely on deprecated functionality. I also dread the complete dropping of controllers.
Controllers weren’t dropped in 2.x, you might find this talk useful: https://www.youtube.com/watch?v=zwb3HvjpG3o&index=1&list=PLaKDKbFmAv-aLYGogQ63zzKeUpy_opDia
For starters, there are things in Ember that feel half-baked. For example, how can I create route that has optional route segment, so I could hide page number from url for first page? Having multiple url’s point to single controller was non-issue back in 2006, yet in Ember.js its challenge enough to ruin your day.
This sounds like queryParams for pagination
Getting custom loading templates for “flat” routes, so you can, say, give UI preview for some list, requires nesting your route under “do-nothing” route for Ember to actually use your loading template instead of app’s default one.
All that’s required is for you to properly name the loading route template for that route, you don’t need to change the organization of your route.
Keeping ember-data’s store size under control was always a problem to me, and eventually I’ve developed habit of emptying it completely every time top-level route was entered, so I knew I’ll get up-to-date models from backend, while not using memory for holding some other stuff I’ll wont need beyond that one page.
You’d need to be grabbing a very very large amount of data for this to have been a concern, but you found one of many right ways to do this if you need to.
Eventually my codebase reached size in which broccoli’s build times entered domain of minutes, meaning every time I’ve hit cmd + s in my editor, I was guaranteed enough time to go make myself tea. And don’t get me started about “go buy SSD” as solution.
There’s a lot of common paths that lead to build slow downs.
- coffee script
- sass
- google-material-design
- no SSD
- no watchman
- not turning off your system’s / IDE’s indexing of
dist
and tmp
- using an older version of ember-cli
Thankfully, with the most recent release of ember-cli, most of these bottlenecks are gone.
From the looks of it, it seems that Ember is still happy to tell you “calling set on destroyed object” error, like it did back when I was starting with it, which today I’m reading as an part of greater issue:
Well yes, if you’re setting on a destroyed object it means you’re doing something incorrectly that needs to be fixed.
Old API’s are being constantly deprecated for sake of new, “better” apis, that don’t add any value to your project
Perhaps not value that you’ve seen yet, but this sort of churn is common in most frameworks, end especially common in frontend frameworks. Frontend frameworks have to iterate to match changing language abilities and changing browser abilities. This churn also induces developers to find better patterns and primitives to use based on newer / more standardized browser and language abilities. 6 months on the front end is about 3 years in the backend dev cycle. That’s also compounded by most front-end devs being either less-experienced devs (having not spent much time learning anything but front-end tools) or back-end devs unfamiliar with what’s really available or possible on the front-end.
but force you to return and iterate closed parts of your project, sometimes actually taking away features that you relied on, forcing you to hack around.
I’d love to know what you had to hack around, deprecations happen when a clear path to something better is released.
reconsider options and conculde that reimplementing whole thing on something else will take same time it would take to catch up with deprecations,
You don’t have to replace deprecations unless you want to use the next major release. Deprecations aren’t removed until major releases.
- Iterate over an array of ember-data objects in your controller/component.
You iterate an array however you’d like. for in
, for
, while
, Array.forEach
, Array.map
, Array.filter
, Array.sort
. In short, you use the native JS APIs.
- Make it more obvious how to access the model in the controller/component if needed.
I think templates have gotten sufficiently involved we should add a page to the docs on how components in a route can inter-operate / how blocks and yields work.
- Explain how to create a screen that uses multiple data elements, especially where 1 isn’t specific to the current route (think of user profile information in a header and then a list of blog posts in the main body. It’s not clear, and no examples show how/where the call to the user profile stuff resides).
import Ember from 'ember';
const {
inject,
Route,
RSVP
} = Ember;
export default Route.extend({
session: inject.service('session'),
model(params) {
return RSVP.hash({
user: this.get('session.user'),
foos: this.get('store').find('foo'),
bar: this.get('store').find('bar', params.id)
});
}
});
But I think it’s also a problem that we are only focused on fixing the documentation for the newest versions.
This is necessary, it’s a highly complex and nearly impossible task to fix the docs for older versions. You end up needing commits applied to the docs for N versions, which you must determine the correct range for, it’s not enough to PR a change to one version. If you’re using 1.13.x
though, the docs for 2.0
are equally valid if you’re seeking becoming deprecation free.