Ext JS Application Development Blueprints

Rather than writing code that is for a hobby or side project, we're now writing applications that help run businesses. Someone is paying for this development time, and someone's livelihood is relying on it. As professional software developers, we need to adopt a professional mindset and skillset to match. Rather than coming up with an idea and sitting down to code it immediately, we need to carefully consider how our application is constructed. We need to ensure that it will work as expected when real-world users get their hands on it; this will provide a strong platform for future developers to build on.

As software developers, we can be responsible for tens of thousands of lines of code—and in many cases more—and may be working in a team comprising a range of other individuals. At this scale, badly designed applications can become unwieldy, unreliable, and difficult to test.

It's unwieldy because without a strong design, functionality is tacked on as it's required, building on an already shaky foundation; unreliable because this shaky foundation has cracks crawling with bugs, and difficult to test because the system's parts are so intertwined that each component doesn't have a clear set of responsibilities and capabilities.

This is the danger of taking an idea and running with it; you may be creating code that grows out of control like a weed in a garden. A design is the key because it allows you to be the gardener (carefully tending each facet of the system as it grows). We want to create a clear, positive structure for our team members to start from and build on.

The structure we want to create in an application should give us clear delineation between one component and another. Each part of the system should be responsible for itself and nothing more (a small part in a larger machine). The layers of our code (from data to presentation and all the wiring in between) should also be clear-cut because no one wants to see a template talking directly to a backend service.

This is a classic example of overlapping concern. In this presentation, code should never have to worry about fetching data, only how to present it. This, and many more such issues, can be easily avoided with a strong structure and application design that is implemented from the start.

Many have gone on this journey of scalability before us. It's worth remembering that there are many formal metrics to help us determine whether our code is too complex. "Cyclomatic complexity" is one example, a technique that evaluates details (such as code cohesion and branching depth) and can be tied into automated systems that raise a warning when a threshold for complexity is crossed.

In reality though, such metrics are a method of firefighting complexity rather than planning to avoid it. By looking at ways in which we can structure our code for success, we can minimize the need for such automated checks.

The first stop must be object-orientated programming (OOP). By encouraging a piece of functionality to be encapsulated in a class, we immediately impose a sense of separation in our application. Just as splitting our multi-hundred-line script into separate chunks made sense, here we can formalize this approach by creating classes that take responsibility for a single piece of functionality.

With the photo gallery, the pagination is a great example of where concerns could overlap. My original implementation just had a lot of loops and conditional statements wrapped up with the HTML. Instead, we can have one class that does the logic of the pagination (for example, whether the "next" link is available) and another class responsible for generating the HTML based on this data.

In Ext JS 4, Sencha brought in a new class system that allows you to better create objects that encapsulate application functionality as well as a strong application framework. Ext JS 5 builds on this and adds some extra features to make the Ext JS application architecture ideal for everyone (from individual developers to large teams). The structured approach that it makes available allows you to scale a code base while keeping its foundations strong.

A software project should never begin without a list of requirements from the customer, client, or other stakeholder. This is often in the form of a detailed specification document. Requirement analysis involves the architect understanding the problem that needs to be solved and applying what they've learned to the next stages of the process.

Here's a short example:

Users should be able to log in, log out, register, and request a new password. Login should be persistent across browser sessions.

The architect reads this and the developers (in turn) end up with the following code to handle user logins:

Ext.define('MyApp.SessionManager', {
    login: function(username, password) {
        User.login(username, password, {
            success: Ext.bind(this.loginSuccess, this)
        });
    },
    loginSuccess: function() {
        this.isLoggedIn = true;
    }
});

This should be familiar to a seasoned Ext JS developer: we use Ext.define to create a class called MyApp.SessionManager. The login method contains an invocation of a login method on the User class and triggers a callback if it succeeds. Using Ext.bind, we set the scope of the success callback to the SessionManager class and when it's called, we set the isLoggedIn value to true. Further code would then redirect the authenticated user to the rest of the application.

The problem is that the architect has not correctly processed the requirements. They have missed the second part (the part that mandates that logins should be persistent across sessions). In this code sample, we store the login state in memory. To support the requirements, we should use a cookie, localStorage, or some other storage mechanism to make the login available between browser sessions. What will this code look like? Let's tweak this class a little, change one method, and add a few more methods:

loginSuccess: function(userDetails) {
    this.setUser(userDetails);
},

isUserLoggedIn: function() {
    return window.localStorage.getItem('user') === null;
},

setUser: function(userDetails) {
    window.localStorage.setItem('user', Ext.encode(userDetails));
},

getUser: function() {
    return Ext.decode(window.localStorage.getItem('user'));
}

The replacement loginSuccess method passes off to setUser, which makes use of localStorage to persist user details across browser sessions. We also provide an additional isUserLoggedIn method to check localStorage for any user details and a getUser method to grab these details. Note the use of Ext.encode and Ext.decode to convert JavaScript objects to strings that can be inserted into localStorage.

This is a more realistic implementation of this functionality that needs to be better specified at a higher level. Without translating this requirement from the client's stipulations through to the developer's instructions, we'd be omitting an important part of the application's feature set.

As with much of the application architecture, it will be a collaborative effort between the architect, developers, database administrators, and other members of the technical team. Data design is the result of a discussion about the data you need to store, where it will be stored, and how this will be reflected in the stores and models in your Ext JS. Let's look at a theoretical requirement for an application:

After three failed login attempts, the user account will be locked for 30 minutes.

This means that we need to record the number of failed login attempts and the last login attempt in the User model or some other persistence method (such as a server-side database). Without it, we wouldn't be able to create the correct client-side logic and UI to support this requirement.

Perhaps, the bulk of an architect's work comes from structuring the application's code base. Depending on the size of the team, the architect may or may not be involved in writing the code itself, but they will have intimate knowledge of the application at a higher level (almost certainly at the class level and in important situations at the method level). In many cases, UML or other diagramming tools will be used to provide a way of recording and sharing the design, as shown in the following diagram:

A UML-like diagram showing the models in a theoretical music application

The Album class that comes from this would look like the following code:

// model/Artist.js
Ext.define('MyApp.model.Artist.', {
    extend: 'Ext.data.Model',

    fields: [
         { name: 'name', type: 'string' }
    ]
});

// model/Album.js
Ext.define('MyApp.model.Album', {
    extend: 'Ext.data.Model',
    
    fields: [
         { name: 'name', type: 'string' },
         { name: 'artist', reference: 'Artist' }
    ],
    getRunningTime: function() {
          return this.tracks().sum('lengthInMs');
    }
});

// model/Track.js
Ext.define('MyApp.model.Track.', {
    extend: 'Ext.data.Model',

    fields: [
         { name: 'title', type: 'string' },
         { name: 'lengthInMs', type: 'integer' },
         { name: 'album', reference: 'Album' }
    ]
});

We define fields with the reference config to set up a many-to-one relationship between artists and albums, and albums and tracks. The getRunningTime method, which was shown in the previous class diagram, is an example of an area that an architect might not get involved in (they can leave the implementation details of this method to a developer).

This is the key aspect of architecture that we'll be covering in this book.

In this book, we will discuss Ext JS 5, so our technology choice should be fairly straightforward! Nonetheless, it's important for an architect to evaluate all of the relevant parts of their technology stack to ensure that it supports the product requirements. Here are some technology questions that are still relevant in our situation:

All of these have potential ramifications that an architect must evaluate while planning a project.

In the same way that a building architect must make sure the design they create adheres to building code and safety regulations as well as ensuring the materials they use will create a pleasing finish, software architects must also take steps to guarantee the quality of the finished product.

Naming conventions, formatting guidelines, a process to deploy the application—all these contribute to having a professional workflow that makes it easy for the developers and project to succeed. The architect is the guiding hand, bringing the customer something that exceeds their expectations.

There are many reasons why documenting the development process is a good idea. For example:

Having a single point of reference for the design documents helps in a large team and assists with bringing new team members up to speed. It's a very bad idea for the architect to hold all of their ideas in their head, and it's a very good idea for this knowledge to be shared, discussed, and recorded. Such documentation might come in a variety of forms:

Code documentation will often be automatically created as part of a build process, but an architect will be responsible for mandating this code to be documented and instituting a build step to generate it. Other forms will be part of a manual process and can involve the client, the development team, and the architect.

In the next few pages, we'll look at how software and software developers can find themselves in possession of an unwieldy code base, what makes it unwieldy, why it's a problem. We'll also look at the attributes that make for a well-architected software product.

Let's take a look at a classic piece of example code from back in the days of Ext 3.4:

// View a working version at https://fiddle.sencha.com/#fiddle/90s

// Basic JSON sample data
var sampleData = { data: [
    { "firstName": "Jack", "surname": "Slocum" },
    { "firstName": "Shea", "surname": "Frederick" },
    { "firstName": "Colin", "surname": "Ramsay" },
    { "firstName": "Steve", "middle": "Cutter", "surname": "Blades" },
    { "firstName": "Nigel", "surname": "White" },
] };

// Create a store to hold our JSON data
var userStore = new Ext.data.JsonStore({
    data: sampleData,
    root: 'data',
    fields: ['firstName', 'middle', 'surname']
});

// Grid panel using the store, setting the columns to match the incoming data
var grid = new Ext.grid.GridPanel({
    store: userStore,
    colModel: new Ext.grid.ColumnModel({
        defaults: {
            width: 120,
            sortable: true
        },
        columns: [
            { header: 'First Name', dataIndex: 'firstName' },
            { header: 'Middle', dataIndex: 'middle' },
            { header: 'Surname', dataIndex: 'surname' }
        ]
    }),
    viewConfig: {
        forceFit: true
    },
    width: 600,
    height: 300,
    frame: true
});

// Event handler to do something when the user clicks a row
grid.on('rowclick', function(g, idx) {
    Ext.Msg.alert('Alert', 'You clicked on the row at index ' + idx);
});

// Render the grid to the viewport
grid.render(document.body);

This block of code should be familiar to the reader as something that generates a populated grid:

When a row on the grid is clicked on, an alert box appears showing the index of the target row. This is all well and good. It represents a fairly typical example of what you'd have seen in the Ext JS documentation at the time of Ext JS 3.4.

So, what's the problem? The problem is that this code does everything. It sets up our data store, drawing JSON from either a remote or local source. It creates the grid itself along with its many configuration options. It sets up event handling code to pop up the alert box. And after all that's been done, it finally renders the grid to the screen.

Within a simple piece of code like this, the problem is less pronounced. Although, when more functionality is added, such as paging or a detail window popping up with further information about a record and tying all of this into a larger application with server-side interaction, multiple screens, and so on, then things start to get tricky.This is the type of issue that Sencha tried to resolve by introducing defined architectural practices in Ext JS 4. Rather than putting everything together and mixing all these different concerns, the idea was that they could be pulled apart into more logical, concise, and distinct objects.

The model-view-controller (MVC) pattern was the choice of the new wave of web developers. Ruby on Rails had already popularized MVC and many other major frameworks had brought their own ideas to the table.

Ext JS 4.0 was released on April 26, 2011, over 4 years after v1.0, and many developers were already comfortable with using the MVC pattern in their server-side apps. Frameworks (such as Backbone.js) had slowly begun to give developers the tools to use such architectural patterns in their client-side code. Ext JS 4 needed to do the same and it delivered.

Prior to version 4, Ext JS had stores and records (the "model" in MVC). It had components or widgets (the "view" in MVC). The architectural issue was twofold; how did models and views talk to each other? How did we avoid making our views bloated with logic code?

One answer was to introduce the controller concept. This allowed us to create a layer of glue to create stores, hook them up to components, and use events to manage communication between all of these parts of the application.

In version 5 of Ext JS, a couple of extra features fully answered our architectural questions with ViewControllers and ViewModels. ViewControllers allow us to separate out logic code in our views into a distinct class, ensuring that both the view and ViewController can focus on their own set of responsibilities.

As well as building classes into the Ext JS framework to help us build complicated applications, Sencha has also provided a number of supplementary tools that assist with the development process. In particular, Sencha Cmd is a powerful command-line tool that introduces some indispensable facilities.

From the beginning, Sencha Cmd can help by generating the directory structure of your application with a best practice layout, specifically created to help with the new Ext JS 5 cross-device support. You can add new models, controllers, and so on, all from the command line.

As you're developing, Sencha Cmd can help you by compiling theme files, slicing and dicing images, and running a development web server to run your code locally. Also, during testing and deployment, it can package your code into an optimized bundle to give your users the minimum amount of code to download in their browser.

Sencha Cmd is a great example of a product that is growing up. It represents a key piece of your development infrastructure and a fantastic complement to the Ext JS framework itself.

How do you design an application without knowing what it is you're designing? This is what a specification provides. A document or series of documents that describe in exacting detail how the features that make up your software should behave. It's a continuing mistake in the software business that we don't collect the requirements of our users and clients before we start writing code. In the same way that it's irresponsible to build an application without architecting it correctly, it's irresponsible to build an application without being as certain as possible that you're creating the correct thing for a paying customer. What sort of issues can a specification avoid? Some of them are as follows:

This reads as a fairly generic list of things we don't want during our project.

More importantly for the purposes of this book, a specification allows you to have all of the information needed to create your application design. It doesn't necessarily mean our design will be right, but without a specification, you can guarantee the design will be wrong.

Part of creating both a specification and a design is understanding the customer requirements; understanding the "problem domain" that represents their business. It's really hard to write a piece of computer software for a shipping business unless you understand at least a little bit about shipping, for example the way they calculate rates in relation to cargo weight and the distance it's travelling.

In regard to Ext JS, we may be working with an external SOAP API that provides these shipping rates. Well, Ext JS supports working with SOAP (with a Sencha Complete license), but if it didn't, this would probably affect our design—we'd have to write more code to talk to the SOAP API—and therefore our timings.

We're writing a content management system, but it needs to be very closely tied with the customer's branding due to agreements with third parties. Will the Ext JS theming system allow us to incorporate the extensive customization needed for the project?

We started working on a sales portal for a new client when the Finance Director reveals that all his work outside the office is done on an iPad mini. We now have to work backwards to incorporate touchscreen support. If we'd have consulted all of the stakeholders at the right time, we'd have saved weeks of work.

These examples are somewhat contrived, but serve to highlight that application design is not only about software, but also a fusion of consulting the people involved, evaluating your resources, understanding the problem domain, and creating a software architecture. These requirements don't exist in isolation.

Consider bringing a new developer or tester in your team. How quickly can they get up and running with the latest build of your code? How can they track down the code change that resulted in a bug they're working on and then find the developer responsible for the bug? Is there a particular way in which automated tests should be created and new code should be written?

These are all highly important questions when creating a successful application because they reduce the barrier between creating and improving the existing code base and keeping the quality of the resulting code high. Joel Spolsky, of Microsoft and Fog Creek fame, wrote a blog article back in 2000 that is still highly relevant today. Titled The Joel Test: 12 Steps to Better Code, it asked twelve questions of development houses based on Joel's extensive experience working with a variety of coding teams and projects (from Microsoft Excel to Fog Creek's own Trello). The whole article's well worth a read, but we're going to take a fresh look at it with regards to Ext JS development.

Joel's second question, "Can you make a build in one step?"

We mentioned earlier that it needs to be easy for developers and testers to build a final version of your application from the raw source code. This could be the process that compresses your CSS and JavaScript so that your users can download it more quickly. The key is that you want to be testing your work against the same final build as your users to avoid bugs creeping through.

In Ext JS 5, we can use the Sencha Cmd to create development, testing, and production builds and it can even be used to create a packaged version of your application for deployment on touch devices. In doing so, it gives a unified mechanism for your whole team to work from the same build with a single command, making Joel very happy. This also ties into his third question, "Do you make daily builds?" With the tools we've described so far, an automated build system can grab the latest and greatest code from source control, build it using the Sencha Cmd, and deploy it to a testing or beta server for evaluation.

Joel's fourth question, "Do you have an up-to-date schedule?" and his fifth question, "Do you have a spec?"

Of course, neither of these is specific to Ext JS applications, but they're tightly related to the theme of this book. We've discussed having a specification that informs your application design, but it's an up-to-date schedule that goes hand in hand. By designing your application correctly, you are dividing it into sections that can be scheduled by yourself, your team, or your management.

A single controller with its associated views and the required models could be scheduled to take a month to complete, so an app designed to have three controllers could take three months. Joel's sixth question's a little bit more specific than this though, he asks for an up-to-date schedule. This means examining your work to ensure you're meeting your schedule and adjusting accordingly. It also means learning from a slipping schedule and realizing that your design may have been flawed in some ways. A more complex view with lots of interaction will clearly take more time than a simple view, so it's not as straightforward as our "one month per controller" suggestion.

The rest of Joel's questions are more general, so we'll skip them and talk about another important facet of setting up your development process: style. Not what your developers are wearing, but the way in which they write code. There are two things to consider here, the ones related to JavaScript and the ones specific to Ext JS.

The developers of Twitter Bootstrap caused upset in 2012 by opting not to use semicolons at the end of lines of JavaScript and combining that with some slightly obtuse syntax. Refer to https://github.com/twbs/bootstrap/issues/3057.

In truth, it doesn't matter too much whether you use semicolons or not in most circumstances due to JavaScript's automatic semicolon insertion. Refer to http://ecma262-5.com/ELS5_Section_7.htm#Section_7.9.

The more important point is that whatever you do, do it consistently and make sure everyone working on your application is doing it too. Not doing this will have severe consequences for the maintainability of your application as it's developed (imagine having files with two or three different styles of commenting, string quoting, and conditional statements).

Ext JS itself has a couple of conventions that will make your life much easier if you adhere to them. When a controller requires a store, you can do it like this:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    requires: [
        'MyApp.store.Albums'
    ],

    getAlbumsStore: function() {
        return this.getStore('Albums');
    }
});

This is equivalent to:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    stores: ['Albums']
});

As the Store class was defined as 'MyApp.store.Albums', we can refer to it with the 'Albums' shortcut. Likewise, controllers should always have "controller" as the middle part of the class name, "model" for models, and "view" for views.

This is partially covered in the naming conventions segment of the Ext JS 5 Core Concepts guide. What isn't explicitly mentioned is the way that these shortcuts are pervasive across Ext JS and how they can make your code much clearer.