When deploying your Ember.js applications with ember-cli-deploy, working with staging environments can be unintuitive. To do this cleanly you should not think of staging as an environment but in terms of a deploy-target you deploy your application to with a customized configuration. This post shows you how to do this properly.
Sometimes you have a UI where at a certain level you have multiple nested routes and they deal with one parent item. For example if you had a blog management system that supported multiple blogs, you could have a route like dashboard.blog.post.edit and the Blog model is found at the dashboard.blog route. So at this point you want to use that same blog model in the other routes. Historically there has never been a great way to do this, you might think put it on a service, but then you have to register and cleanup that service since services are global. Along with that inconvenience it's also not clear where the service gets its data, it seems a bit magic.
Most Ember developers are familiar with Ember Data and JSON:API, which means that GraphQL and Apollo are not nearly as wide spread in the Ember community. This past year I had the chance to work on an app with GraphQL and Apollo in an Ember app, and I wanted to share some of the things I learned.
Ember Octane has landed along with a large number of new features, but none of these features is more exciting to me personally than autotracking. Autotracking is Ember's new reactivity system, which is what allows Ember to know when stateful values (such as @tracked properties) have changed.
As native classes have stabilized and more and more of the Ember community has begun converting over to them, I've heard a lot of misinformation being spread around about what they are and aren't capable of. This is a pretty important transition for Ember, so I wanted to set the record straight really quickly about a few key things.