Ext JS and ES2015/6/7 – Modernizing the Ext JS Class System

The JavaScript language today is hardly recognizable when compared to JavaScript of a few short years ago. The changes range from small pieces of syntax (such as loops, variables, and functions), up to the level of classes for creating coherent functional units, and extend all the way to connecting these pieces into applications via modules.

Today, through the widespread use of tools such as Babel, Traceur, webpack and others, many developers have embraced these new language features and their code can still run on “those” browsers.

In my session at SenchaCon 2016 (Ext JS and ES2015/6/7 – Modernizing the Ext JS Class System), we’ll talk about how this evolution in language and tools affects the applications we write using Ext JS. We’ll look at how the class keyword compares with Ext.define, and how class names line up with modules. And we’ll compare the two end-states of an upgraded application: one with minimal changes to existing code and one that fully embraces all of the new language features.

Don’t have your ticket yet for SenchaCon 2016? Register today.

Sneak Peak

Class Declarations

Let’s take a simple utility class that might be found in an Ext JS application today and see what an upgrade might look like.

    Ext.define('App.util.Foo', {
        extend: 'App.some.Base',
        mixins: 'Ext.mixin.Observable',
 
        config: {
            value: null
        }
 
        constructor: function (config) {
            this.mixins.observable.constructor.call(this, config);
        },
 
        updateValue: function (value, oldValue) {
            this.fireEvent('valuechange', value, oldValue);
        }
    });

The following diagram shows the important pieces produced by the code above:

Class Declarations part 1

If you look at the constructor property on the prototype, you’ll see that it points to the method we passed to Ext.define. This approach, while flexible, is not compatible with the new class keyword. Using the class keyword produces the following, immutable relationship:

    App.util.Foo === App.util.Foo.prototype.constructor

Minimal Upgrade

The minimal upgrade requires us to rename the “constructor” method to avoid this conflict. The new name is simply “construct“:

    Ext.define('App.util.Foo', {
        extend: 'App.some.Base',
        mixins: 'Ext.mixin.Observable',
 
        config: {
            value: null
        }
 
        construct (config) {
            this.mixins.observable.construct.call(this, config);
        },
 
        updateValue (value, oldValue) {
            this.fireEvent('valuechange', value, oldValue);
        }
    });

Though not necessary, we’ve also taken advantage of the new function property syntax for object literals and removed the “: function” from our methods.

Because the new Ext.define internally produces a standard class, we gain some benefits as well. Consider the following diagram showing what is generated by the upgraded Ext.define call above:

Class Declarations part 2

Because class constructors are now prototype-chained to their superclass constructors, effectively all static members are inheritableStatics for free!

Maximum Upgrade

At the opposite end of the upgrade continuum is a complete upgrade to all the new language features and options. Let’s look at what the fully upgraded version of the above class might look like:

    import { define }     from 'extjs-kernel'; // module names not final
    import { Observable } from 'extjs-core';
 
    import { Base }       from 'app-some';
 
    @define({
        mixins: Observable,
        config: {
            value: null
        }
    })
    export default class Foo extends Base {
        updateValue (value, oldValue) {
            this.fireEvent('valuechange', value, oldValue);
        }
    }

In this version, we’re taking advantage of several new class system features as well as some upcoming JavaScript features.

If you haven’t seen the @define syntax before it’s called a decorator, and it’s an exciting language feature currently being worked through the standardization process. It’s available today via the magic of transpilers. Transpilers are tools that compile JavaScript-to-JavaScript or more precisely, Advanced-JavaScript-to-Browser-Friendly-JavaScript. Through the @define decorator, you can apply all the additional powers of the Ext JS class system to this standard class.

We also removed the construct/constructor methods in this example. This is because the construct method of Ext.Base now provides a Common Object Lifecycle. When called with a single object parameter or if the class uses the Config System, the necessary steps to initialize the instance are handled automatically.

Last, we’re using the new, standard import and export keywords. Support for these is also by virtue of transpilers (because no browser yet supports them). To learn more of the details, you can also attend Ross Gerbasi’s talk: The Modern Toolchain.

Choices, Choices

Because there is no one-size-fits-all approach, the overarching goal of this upgrade is to minimize what must be done to existing code while at the same time enabling developers to use fully modern JavaScript techniques and practices.

To hear first-hand what else is coming, be sure to attend my session at SenchaCon 2016!

Written by

Don is the Engineering Director for Ext JS and Sencha Touch. He was an Ext JS user for 2 years before joining Sencha and has more than 25 years of software engineering experience on a broad range of platforms. His experience includes designing web application front-ends and back-ends, native GUI applications, network protocols and device drivers. Don’s passion is to build world class products that people love to use.


Comments

  1. says

    Doesn’t this “maximum upgrade” syntax trade away the ability to load class source files in any order and asynchronously fetch their dependencies? This seems to also lose the ability to analyze the dependencies of a class source file via a javascript parser.

    Will this new syntax require running some watch tool with an AST parser to continuously line up dependencies for synchronous loading?

    • Don Griffin says

      Hi Chris,

      When using ES6 import, the build tooling handles the loading and evaluation of these scripts.

      In the case of webpack this loading is via a “bundle” file and the contained modules are executed in proper dependency order. from there This is largely invisible in the debugger due to source maps. SystemJS (an alternative to webpack) uses normal, async loading of source code but it then schedules the execution of the modules to respect their import order.

      So, bottom line then is that while the syntax looks like synchronous loading, it is only really sequential evaluation that is going on.

      Yes, a watch process will be an option to keep things up to date on disk.

  2. David says

    I am really excited about the move to support the newer es standards. I am hoping that you post early access releases as soon as possible because this will effect our maven/sencha cmd build process and much of new code.

  3. Edouard says

    Nice to see Sencha working seriously to Make ExtJS Great Again :-) Just kidding, ExtJS never stopped being great.

    Looking forward for learning more in Vegas.

  4. Don Griffin says

    @David, @Edouard,

    Thanks for the kind words.

    We’ll have lots more info at and then after SenchaCon. We will get bits out as soon as things are baked enough. Stay tuned and thanks for the feedback.

    Hope to see you there!

  5. Psychokrameur says

    Does it means that a transpiler will be integrated in the “standard” SenchaCmd build process?
    If this is the case, it’s a good news!

    • Don Griffin says

      Yes, the output language is configurable for production/testing builds (not in dev mode where we load files individually). The language level support and polyfills are coming from Google’s Closure Compiler (see https://github.com/google/closure-compiler/wiki/ECMAScript6 for more details).

      Cmd 6.5 has its own minifier to replace YUI. This is currently the only minifiier that does not require you to transpile down to ES5 first. So that means you can opt-out of transpiling for production and leave your ES6 code “as is”… when that makes sense for your target browser(s).

        • Don Griffin says

          It’s a new compressor similar in spirit to YUI – just renames locals and does some other minor minifications. Slightly better compression on ext-all.js than YUI and can operate on pure ES6 w/o transpilation :)

    • Sebastian says

      Follow up: I just noticed that Closure Compiler also supports ES6.

      So what’s the advantage of your own minifier over using Closure (or Babili)

      Sebastian

      • Don Griffin says

        Hi Sebastian,

        As it currently sits, Closure’s compressor has two issues. First, its renamer breaks a couple things due to eval() usage. Second, you have to transpile to ES5 in order to compress the code. The Cmd minifier works against the full ES6 tree.

        I haven’t looked at the Babel compressor yet because we don’t provide Node.js with Cmd and also do not require it as a system dependency. One could just use Cmd to produce a testing build and then run any compressor against the output, but in testing using uglify, it was significantly slower the YUI (which is on par with the new Cmd compressor).

        We will be looking at Node.js-based solutions more closely for our next major release of build tools that we announced at SenchaCon, so stay tuned for details there.

        And thanks for the feedback :)

Leave a Reply

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