Simulmedia’s UI Team Upgrades to Ember Octane

The UI team at Simulmedia recently made the decision to upgrade its version of Ember, our front-end framework, to utilize Octane, an update that adds myriad new features for cleaner, more effective code. Let’s take a look at some of the changes that Octane brings to the Ember experience:

Generating Ember Components

One of the first notable changes is the way in which we create components from the command line. Although this doesn’t represent a huge change, it is important for a few reasons.

Previously, we would generate a component in Ember with the following command:

ember generate component my-component-name

This command is pretty straightforward and helps us to generate three files: a JavaScript file, a Handlebars template, and an integration test for the component that we just generated.

In Octane, we have a slight modification that allows us to customize the files that we generate with this command. For example, we can append an option to generate a Glimmer component, which is what we call components in Octane. Additionally, we can add an option to generate a classic component, which refers to the components in previous versions of Ember, like the one we generated above. Let’s take a look at how these commands look.

//‘gc’ stands for ‘glimmer component’
ember generate component my-component-name -gc

//‘cc’ stands for ‘classic component’
ember generate component my-component-name -cc

There are a few key differences between the two commands. First, adding the ‘gc’ flag indicates that we are using a Glimmer component, which entails using new syntax and features in Octane. Conversely, if we want to use syntax and features from previous Ember versions, we can add the ‘cc’ option to indicate this.

Rendering Glimmer Components

Another new feature of Octane is the new syntax for rendering our components in templates. Rather than using the traditional, double curly bracket syntax, Octane utilizes the new bracket notation, which is analogous to the syntax found in the React framework.

New Octane syntax:

<MyComponent @arg={{this.firstArgument}} />

Nested components in Octane are specified as such:

<Nested::MyComponent />

Classic Ember syntax:

{{my-component arg=firstArgument}}

Classic nested component:

{{nested/my-component}}

Although not a huge change, I truly believe that it makes the code more readable, and, ultimately, that is one of the primary goals and advantages of upgrading to Ember Octane.

Passing Arguments from a Parent Component

One of my favorite changes implemented in Ember Octane is the notation that we use to specify an argument that has been passed from a parent component, as well as the way in which a component utilizes its own properties.

Octane syntax for passing down an argument:

<div>{{@argument}} is passed down from the parent</div>

Classic syntax:

<div>{{argument}} is passed down from the parent</div>

Likewise, the way in which we utilize a component’s properties in the template is slightly different. Consider the following:

New Octane syntax:

<div>{{this.componentProperty}}</div>

Classic syntax:

<div>{{componentProperty}}</div>

In my opinion, this is a welcome change, as it helps us to differentiate between a component’s own properties, and those that have been passed down as arguments from a parent component. Just another example of how Octane makes code more readable!

Decorators Everywhere!

A change that definitely takes getting used to is the use of decorators in components, controllers, and routes in Octane. They’re everywhere! From the new tracked property to actions to classic components, Octane makes good use of decorators, originally introduced in ES2015+.

As we discussed above, with the implementation of Octane, we can utilize two types of components: Classic components and Glimmer components. In Octane, this can be accomplished by adding the @classic flag above the export statement:

@classic
export default class MyClassicComponent extends Component {}

This indicates to developers that Classic Ember syntax will be utilized. Glimmer components do not have a decorator; additionally, there are several other ways in which Glimmer and Classic components are different, but this is the most-obvious.

However, the use of decorators does not end there! Decorators in Octane are used with actions, tracked properties, importing services, and more. Let’s take a look at how a typical Glimmer component might look:

export default class MyComponent extends Component {
 @service store;
 @tracked isOpen = true;

  constructor() {
    super(...arguments);
    this.data = {
     name: 'Michael',
     index: 1,
    };

    this.changeset = new Changeset(this.data);
  }

 @computed('index')
 get nextIndex() {
   return this.index + 1;
 }

  @action
  setName(name) {
    this.changeset.set('name', name);
  }
}

Although not a massive change, I am a proponent of decorators in Octane, as I feel that they again add a bit more context and readability to our code. Also note that computed properties have a new look, and, as a general rule, Octane advocates for the use of simple getters over computed properties, although there are some exceptions.

The Last Word

To sum up, I am a fan of a lot of Octane’s new features, although it did take a bit of time to fully understand and appreciate them. The UI Team at Simulmedia still faces a big task ahead in updating our code base to reflect the latest conventions in Ember. Overall, sentiment is good; as developers, we have accepted the changes with open arms, and the general consensus is that Octane really does make Ember code more readable and easier to understand. So, are you ready to turn up the heat with Octane?