Ember.js: Octane Edition is Here

Ember 3.15 is Octane! Curious what Octane means for web development? This blog post will get you oriented. For a write up of the technical details (upgrade strategies, deprecations, new Ember Data features) see the Ember 3.15 Release blog post. What is Ember Octane? Ember Octane is the best way for teams to build ambitious web applications. Ember has always focused on building the best framework that people with different levels of skill can use together to build web applications. Octane updates Ember’s components and reactivity system to make them more modern, easier to use, and just more fun. The Ember Project Recommends Octane As of Ember 3.15, the Ember project recommends Octane for new applications and addons. If you create a new app using ember new with 3.15 or later, you will get a new Octane application. Octane is More Fun The Ember Octane edition is, first and foremost, about making it easier and more fun to build Ember applications. The centerpiece of Octane’s ergonomic improvements are two big changes to the core of Ember: a new component model and a new reactivity system. For existing Ember users, both the new component model and the new reactivity system are fully opt-in and fully interoperable with existing code. Upgrading an Ember 3.14 app to Ember 3.15 is a compatible change, as the version number would suggest. Glimmer Components The first big improvement in Ember Octane is Glimmer Components. Ember has had a single component system since Ember 1.0, based on JavaScript syntax that was available at the time. Before: Classic Components The thing that jumps out at you when you look at classic components is that you configure a “root element” using a JavaScript microsyntax. After: Glimmer Components In contrast, Glimmer components allow you to treat the root element like any other element. This substantially simplifies the component model, eliminating the special cases that come from having a second API just for working with the root element of a component. It also means that you can create a component with no root element at all, and things like this just work. Reusable DOM Behavior With Modifiers The second big improvement to the Ember component model is element modifiers, a feature that allows you to build reusable DOM behavior that isn’t connected to any specific component. Before: Mixins In Classic Ember, if you wanted to define a piece of DOM behavior that you could reuse across your application, you would define a component mixin that implemented the appropriate lifecycle hooks. For example, let’s say we have a third-party library that exposes activateTabs and deactivateTabs functions, both of which take an element. In Classic Ember, you could write a mixin like this: And then you would use it in a component like this: The drawbacks of using mixins for UI composition are well-described across the JavaScript ecosystem. The most glaring issue is naming conflicts. Any method on a mixin might conflict with a method on any other mixin, with no good way to resolve the conflicts. In the context of Ember, there’s another issue with using Ember Component mixins for reusable DOM behavior. If you want to use the Tabs mixin on an element, you need to turn that element into a component with a JavaScript class, which is pretty awkward. While we do recommend you avoid mixins, you can still use them in Ember 3.15. Addons may also still provide mixins for you to use. After: Element Modifiers Ember Octane provides a new way to reuse DOM behavior: element modifiers. The simplest way to write an element modifier is to write…

Like to keep reading?

This article first appeared on blog.emberjs.com. If you'd like to keep reading, follow the white rabbit.

View Full Article

Leave a Reply