Octane will be launched in v3.14


Update: Since this article was originally published, the timeline has changed and Octane is not 3.14.see Octane release update Learn about the latest news.

The Ember community is working on Octane number, We hope to pass the finish line in time in v3.14! Ember Octane describes a set of new features that, when combined, represent a fundamental improvement in the way you use Ember. It has modern, simplified components and state management that make building web applications fun. Through seamless interoperability with existing applications, teams can migrate at their own pace, while developers building new applications start with the best available from Ember.

This article will introduce the release plan and how your team can prepare.

Release plan

  • The next version of Ember is 3.12, which is an LTS (Long Term Support) release candidate.View Post a blog post Find out which features of Octane are already available in stable versions like this.
  • Ember 3.13 will provide full functionality for Octane, and applications that use stable Ember can choose to join. At this point, we are still improving, especially in code modules, checkers, and guides.
  • In Ember 3.14, Octane will be the main recommended way to use Ember. In Ember 3.14, new applications will enable Octane’s optional features by default. Guides and tutorials will show Octane examples and will provide code modules to help users migrate to Octane.

Octane function is optional, This will continue to apply to the rest of the 3.x series.As Semantics It is recommended that all versions up to 4.0 are backward compatible with 3.x.

If there are any major changes to these plans, we will update this post.

Remaining work

Since Octane was first released, more than one hundred contributors have been working hard to test it and release it as a stable version. Continue to work at full speed on codemods, learning resources, Ember Inspector and our public website.Anyone interested in helping with these final steps are invited to join #st-octane Channel open Man disharmony.

Prepare your application for Octane

Ember Octane is a series of exciting features, many of which have been released in stable versions. If your team wants to get ahead, you can do some preparations today.

Visit the Octane migration channel on Discord

Man disharmony There is a new channel called #topic-octane-migration You can ask any questions here or get help in the process.If you are new to Discord, please visit #discord-server-admin Request permission to post.

Update your app to 3.12

After publishing, update your app to 3.12. Embers cli update Will help you!

Class review

Octane uses Native JavaScript class, So we recommend that developers try them with regular JavaScript examples to understand the basics (if they are not already familiar). Without some kind of background knowledge, it will be difficult for developers to tell which parts are specific to Ember and native JavaScript syntax.

Try to use the Octane function that has been logged in

The rest of the following sections describe the optional features in Octane that you can consider now. These characteristics are independent of each other. You can select one at a time in any order. The best way to try them is when writing new components.

You will be able to use the codemod that we will complete in Ember 3.14 to automatically migrate many idioms to Octane. When we say “Octane idiom”, we are referring to Octane’s syntax, API, and patterns.We do not recommend trying to migrate old code on a large scale (e.g. @ember/component Component) without those code modules.

Even so, many teams may not want to convert old code at all, but just start using Octane idioms. This is an effective and fully supported method. We will have an upgrade guide describing the options and strategies we will finalize in Ember 3.14. At the same time, all Ember guides and tutorials will be fully migrated to Octane idioms.You can catch a glimpse of these ongoing learning resources Here!

Stability characteristics tour

Below are some of the features that will play a key role in Octane. These are the stable features that have been released.

Application template wrapper

In classic Ember, your entire application is automatically packaged in one <div> With the class ember-application. The Octane application does not automatically insert this unnecessary <div>.

If your CSS (or JavaScript) depends on this <div>, You can explicitly add it to your application.hbs Or refactor your code to no longer rely on it.

You choose to accept this change in the following ways

ember feature:disable application-template-wrapper

jquery-integration

In classic Ember, jQuery is automatically included, and this.$ JQuery is used inside the component class to select from the DOM. Ember Octane does not automatically include jQuery, nor does it include any direct jQuery integration in the component API.

Ember no longer depends on jQuery internally.If your application still uses jQuery directly, and you want to continue to use it, you can add @ember/jquery For you package.json And disable this classic feature. You can still use all other features of Octane.

Alternatively, you can no longer use jQuery in your application, but this is not required. Either way, other functions of Octane can work normally.

You can choose to accept this change in the following ways:

ember feature:disable jquery-integration

If you still want to use jQuery in your application, make sure to add @ember/jquery For you package.json.

Only template shimmer components

In classic Ember, components that have templates but no JavaScript files will be assigned a default component (EmberComponent.extend()). This means that you can use two-way binding to reference properties on this implicit component, and these properties will be implicitly created for you.

Octane will not implicitly create component classes for you, and this The context within the template is undefined. You can still use @name And succumbed to block use yield, But a reference to a property on the component, such as {{someProp}} or {{this.someProp}} it does not work.

Enable template-only-glimmer-components You will be selected to accept the new behavior. The easiest way to migrate an existing application to this flag is to create an explicit JavaScript file for each template-only component that references properties on the implicit component.

Alternatively, you can eliminate any references to implicit components by renaming the parameters {{someArg}} to {{@someArg}} And eliminate any dependence on the two-way binding of implicit components.

When you are done, you can choose to add new behaviors:

ember feature:enable template-only-glimmer-components

Glimmer component base class

One of the biggest changes to the Ember idiom in Octane is the recommended component base class.

In classic Ember, the component base class is @ember/component Then you use it to extend Component.extend().

// Classic, NOT OCTANE
import Component from "@ember/component";

export default Component.extend({
  // class definition here
})

In Ember Octane, extend from a new base class: @glimmer/component And use native class syntax.

import Component from '@glimmer/component';

export default class extends Component {

}

The Glimmer component is a streamlined component base class that does not depend on Ember.Object. It also did not have a proliferation of APIs for configuring root elements, such as classNameBindings, this.element And attach the event handler to the root element.This is because the component inherited from @glimmer/component There is no root element at all.

Glimmer components are fully compatible with classic components and other custom components. You can call Glimmer components from classic templates and vice versa. You can use the Glimmer component in the block passed to the classic component, or you can use the classic component in the block passed to the Glimmer component. This is a complete mix and match.

Attach life cycle events to where they belong

This @ember/component The base class has life cycle hooks, such as didInsertElement with didUpdateElementEmber triggers these hooks at the appropriate time, and you can use them to manage the component’s DOM.

Ember Octane introduces a new method of managing the DOM directly in the template, which can be combined with the classic Ember and Octane.

<h1>{{@title}}</h1>
<div {{did-insert this.fadeIn}} class="alert">
  {{yield}}
</div>
export default Component.extend({
  fadeIn(element) {
    element.classList.add('fade-in');
  }
});

This syntax is called a “modifier” because you can use it to modify elements.It reduces bookkeeping because Ember runs automatically did-insert Whenever an element is added to the DOM.

{{#if this.shouldShow}}
  <div {{did-insert this.fadeIn}} class="alert">
    {{yield}}
  </div>
{{/if}}

In the classic Ember, make sure fadeIn The method is called every time a div is inserted, even if this.shouldShow Being switched over and over again. Because the modifier is attached to the DOM element instead of the component, Ember can call it at the right time.

This is especially useful when dealing with loops.

{{#each @todos as |todo|}}
  <li {{did-insert this.inlineEditor}}>{{todo.name}}</li>
{{/each}}

In this example, every time a new one appears, we will run a bit of JavaScript code li Is inserted into the list no matter how many times it occurs.

and also did-update with will-destroy, Its behavior is as you wish.

Modifiers are everywhereThey work inside classic components, routing templates, and template-only components.

One last thing: if you find yourself writing the same did-insert Multiple codes can be decompressed into Custom modifier, Can even be packaged into plug-ins.A cool example Custom modifier Already on npm is ember-did-resize-modifer, Which allows you to attach custom logic to the element when the element changes size.

<div {{did-resize this.onResize}}>
  Resize the window to see the modifier in action
</div>

Custom modifiers provide a more composable way to package DOM behavior than mixins, which is a typical method in classic Ember.

This {{on}} Modifier

In classic Ember, you can add event handlers to the root element of the component by adding methods to the class.For example, to handle clicks on the root element of a component, you need to add a click Method to your class.To handle events on other methods, you would use {{action}} Modifiers to handle the event and nest the method in actions Hash.

When using the Glimmer component, you can use the new {{on}} Modifier. Since the Glimmer component does not have a root element, {{on}} Work anywhere.

<h1 {{on "click" this.toggleBody}}>Hello world</h1>

{{#if this.showingBody}}
  <div>{{yield}}</div>
{{/if}}

For more details, see API documentation.

Required {{this}} In the template

In classic Ember, you can refer to the properties on the component as {{propertyName}}. This is not clear with helper programs and components, and in RFC 308.

No matter which component you use, you should start using this Reference the component properties in the new code.This no-implicit-this The template lint can help you avoid accidentally using this deprecated pattern.

Ember 3.14 will finalize a codemod, which uses the dynamic information of the startup application to automatically insert this Where needed. We recommend waiting for this codemod to complete before attempting to migrate your code base on a large scale.

Angle bracket call

This one landed not long ago, and many people have already started using it in their apps. In classic Ember, you would use curly brace syntax to call components:

{{input value=this.name}}
{{#link-to route=this.routeName}}Some content{{/link-to}}

Octane introduced a way to use angle brackets and @names.

<Input @value={{this.name}} />
<LinkTo @route={{this.routeName}}>Some content</LinkTo>

In addition to being easier to read, this syntax can also pass HTML attributes directly to the component.This means there is no longer a need to maintain a list attributeBindings In your component. It also makes it easier to attach ARIA properties to components, including components from plug-ins.

You can use angle brackets to call any type of component, including inherited from @ember/component.

see Angle bracket syntax conversion guide more details!

Native class syntax

You can use native class syntax to subclass from any framework base class.This means you can migrate components inherited from @ember/component To the native class syntax.

Native problems

There are some problems when subclassing using native class syntax @ember/component (Many of them involve init method).To help alleviate these problems, you can attach @classic The decorator of the inherited class Ember.Object (Directly or indirectly) and use Ember lint to help find potential problems.

import Component from "@ember/component";

@classic
export default class extends Component {
  init() {
    // potential problem -- switch to using the constructor instead
  }
}

use @classic Now decorator, install ember-classic-decorator And enable classic-decorator-hooks with classic-decorator-no-classic-methods in .eslintrc.js

thanks for reading!

If you have more questions, please visit Man disharmony with #topic-octane-migration channel!

Leave a Reply

Your email address will not be published. Required fields are marked *