Optimizing The Development Process With Sencha Cmd 5

Sencha Cmd provides a suite of tools for generating and building applications using Sencha frameworks (Ext JS arguably the best javascript framework and Sencha Touch). In addition to these bookends of the development process, Sencha Cmd also provides useful tools for your everyday development. From a built-in web server to package management, Sencha Cmd can help you automate many common tasks. In this article, we will explore how all this comes together and test it out with a new custom component.

In a previous article, we covered some of the basic commands in Sencha Cmd that you can use to create and build applications — demonstrating how you can smoothly integrate with your existing systems and deployment processes. In this article, we’ll take a look at updates specific to Ext JS 5 and Sencha Cmd 5.

What about Sencha Applications?

The recommended practice for authoring Sencha applications is to create one source file for each class based on the Sencha Class System. Anyone familiar with Java development will recognize this convention. This is a proven method for organizing large bodies of code for readability and maintainability, and it is also easy to debug when using the dynamic loader because each file is loaded independently.

For small applications, combining this approach with the “ext-all.js” file (which contains the entire Ext JS framework) could be viable for production. For most real world applications, however, this same structure is not suitable for production because of the many HTTP requests required to load all of the classes. Further, these requests have to travel over a much slower network, which means the cost to load each file is much higher than one would experience during development.

Using Sencha Cmd, you can take your Sencha application from its ideal development form and create a minimized, optimized and compressed form that is ready for production.

• Minimized – Only the classes you need will be included.
• Optimized – High-level constructs in your code are replaced with equivalent and more efficient forms.
• Compressed – Commonly called “minification” this is the rewriting of descriptive variable names to single letters and updating all references to match.

How can I get started?

To make this process as simple as possible, Sencha Cmd provides a customizable build script as part of a “starter”application. Don’t worry if you already have an application, because you can generate the missing pieces you need on top of an existing application.

With Sencha Cmd installed, you can go to a suitable folder and run this command to get an Ext JS 5.0.1 application generated and ready to go:

        sencha generate app -ext MyApp myapp

In the “myapp” folder, you’ll find an Ext JS application named “MyApp”. The first time you run this command on a machine, Sencha Cmd will download the Ext JS 5.0.1 package. Once cached locally, Sencha Cmd will then extract the needed pieces and generate the application.

This new application can be immediately built and shipped to production (though with little fanfare) like so:

        cd myapp
        sencha app build
        scp -r build/production/* user@prod:/var/www

What is the Development Workflow?

As important as these two endpoints may be, developers spend only a small part of their day dealing with them. Most developers spend the majority of their time working on JavaScript or Sass (or CSS). The optimal process here is to make changes to these files and reload the page in the browser to see the results.

There are two primary things that a Sencha application needs in place to enable “development mode”: a build of the necessary Sass into CSS, and an appropriate configuration for the dynamic loader (called the ”bootstrap”).

Using App Watch

Prior to Sencha Cmd, these processes were handled manually using Compass and by making calls to Ext.Loader. In a Sencha Cmd application, these steps are included in the build process and can be fully automated using the following command:

        sencha app watch

The watch command starts by performing a special, trimmed down build (of the Sass and bootstrap), launches the web server and then monitors for changes in your application.

        C:Tempmyapp>sencha app watch
        ...
        [INF] Loading app json manifest...
        ...
        [INF] Mapping http://localhost:1841/ to C:Tempmyapp...
        [INF] ------------------------------------------------------------------
        [INF] Starting web server at : http://localhost:1841
        [INF] ------------------------------------------------------------------
        [INF] Waiting for changes...

As changes occur, Sencha Cmd will update the bootstrap and CSS to keep everything in sync. As soon as you save a file in your editor, you will see something like this:

        [INF] Starting web server at : http://localhost:1841
        [INF] ------------------------------------------------------------------
        [INF] Waiting for changes...
        [INF] -----------------------
        [INF] Writing content to C:Tempmyapp/bootstrap.js
        [INF] Writing content to C:Tempmyapp/bootstrap.json
        ...
        [INF] executing compass using system installed ruby runtime
        unchanged MyApp-all.scss
        [INF] Refresh complete in 3 sec. at 06:52:25 PM
        [INF] -----------------------
        [INF] Waiting for changes...

Once “Waiting for changes” appears, we know that the application is ready to reload in the browser.

The watch command is ideal when you are working with Sass because it ensures that your changes are reflected in CSS as quickly as possible. As covered in the Theme Guide, the ordering of Sass files is driven by the corresponding JavaScript file order. This means that as you refactor JavaScript, the order of Sass files can be affected. But not to worry — all of these details are managed by App Watch.

If you are using packages, you can also be sure that App Watch will pick up changes in your required packages as well. Whether you change JavaScript, Sass or simply add or modify resources, App Watch will ensure that all of these pieces are updated. Even changing the package requirements in your app.json will trigger the necessary updates.

What are Recent Improvements To Watch?

If you have used watch in previous releases of Sencha Cmd, you should know that we have made several improvements in recent releases.

In particular, for Mac OS X users, we have revamped the internal filesystem monitor to greatly reduce CPU overhead. We have also improved the monitor’s tracking, so it ignores folders like “.git”.

Can I see Sencha App Watch In Action?

To show how App Watch works, let’s see what happens when we add a requires for an awesome new package, ext-ux-colorpick, to the app.json of our generated application:

"requires": [
"ext-ux-colorpick"
]

We create an instance in the Main.js view:

items: [{
...
},{
region: 'center',
xtype: 'tabpanel',
items:[{
title: 'Tab 1',
items: [{
xtype: 'colorfield',
fieldLabel: 'Color'
}]
}]
}]

Then hit “Save All” and observe the App Watch output:

        [INF] Waiting for changes...
        [INF] BuildEnvironment config change detected : C:Tempmyappapp.json
        [INF] Source File : https://cdn.sencha.com/.../ext-ux-colorpick.pkg
        [INF] Downloading : ....................
        [INF] Extracting  : ....................
        [INF] -----------------------
        [INF] Loading app json manifest...
        [INF] Writing content to C:Tempmyapp/bootstrap.js
        [INF] Writing content to C:Tempmyapp/bootstrap.json
        ...
        [INF] executing compass using system installed ruby runtime
        overwrite MyApp-all.css
        [INF] Refresh complete in 10 sec. at 08:49:37 PM
        [INF] -----------------------
        [INF] Waiting for changes...

We can now reload the page and see the color picker:

You don’t have to use App Watch to use ext-ux-colorpick, of course. To see how this Ext JS 5 component is put together, see the source code in the CmdPackages repository on GitHub. The Readme file will also explain what is included.

What are Manual Alternatives To App Watch?

As handy as App Watch is, there are times when you need alternatives. Perhaps you seldom change the Sass, or you don’t have any RAM to spare. Or maybe the fact that App Watch requires Java 7 precludes you from using it in your environment. In any case, we need to peek into a couple of these high-level building blocks to see the commands that will be helpful and when to use them.

There are three commands that are commonly used when not using App Watch. These are:

        sencha app build development
        sencha app refresh
        sencha ant sass
        sencha ant resources

Let’s look at when each of these commands is needed.

How can I Cover All Bases?

Regardless of what is changed, a development build will ensure that all the necessary pieces are rebuilt:

        sencha app build development

This command includes all the others, so it will take longer than they do, but it will pick up any changes you might make. What is the difference between the new development build and the testing build that has been in Cmd since its first release? The testing build is intended to mimic the production build but with some ability to still debug the application. In a testing build, optimization and compression are disabled but otherwise the outcome is as close to production as possible. In a development build, only the pieces needed to reload from source are performed. In other words, a development build does things like skip JavaScript concatenation and generate a full CSS build (to minimize the need to rebuild the CSS).

NOTE: Sencha Cmd 5 has changed the list of build environments slightly to better manage Cordova and PhoneGap builds. Instead of “native” and “package” environments (which were unique to Sencha Touch), we have added “development” used above. This environment is the minimal build necessary for development purposes. The native and package operations are now handled by the “packager” config (see here for more details).

What Changes in Theme or Package Requirements are there?

If you change your package requirements or your theme in app.json, you should run a development build:

        sencha app build development

This ensures all of the Sass and resources are in sync with your package requirements as well as updates the bootstrap to describe the JavaScript sources from the new package.

Changes in Sass

When not using App Watch, changing Sass is the most common reason to fire up Cmd. If you are just changing the content of a .scss file, then the fastest way to rebuild just the Sass is:

        sencha ant sass

This will pick up changes in the Sass of required packages or themes as well. You don’t need to run “sencha app build development” in this case.

Changes in Resources

If you add a new image to your resources folder or to the resources folder of a required package (or theme), you can update the built resources using this:

        sencha ant resources

This places app and theme resources directly in the “resources” folder. Resources for a non-theme package “foo” would be placed in “resources/foo”.

Changes in JavaScript

Most changes in JavaScript do not require you to run any commands. If you follow the standard naming conventions for folders and files, so the Ext.Loader can properly convert class names into URLs, then you will rarely need to update the bootstrap. This is a good thing to be sure.

The command that updates the bootstrap is:

        sencha app refresh

Then, the question is: “what changes in JavaScript invalidate the bootstrap”?

To answer this question, it is best to sketch out the content of the bootstrap produced by refresh:

• The relative paths to your “app” folder and “src” folders of all required packages (and themes).
• The names of all classes (in your app and required packages).
• The alternateClassNames for all classes.
• The aliases for all classes.

This information enables these conventions in your application:

• Require a class by its alias.
• Require a class by an alternateClassName.
• Require multiple classes using a wildcard (for example, “MyApp.model.*” ).
• Require a class by name that does not conform to the file name conventions.
• Create an instance using an alias, alternateClassName (or non-conforming file name) that is not listed in a “requires”.

If your application makes use of these features, then changes in JavaScript that affect the bootstrap content would require a refresh. Other changes do not require any commands at all.

Another way to look at the list above is to consider it as things to avoid if you are not using App Watch and don’t want to worry about refreshing your bootstrap.

In A Nutshell

If you are not using App Watch, you can typically avoid the need to run commands during everyday development by following the recommended conventions and listing “requires” for the classes you use. In this case, only changes in Sass or in the set of required packages require a build.

You can learn more about the Sencha Cmd build process here.

How can I find out more?

We think you’ll find App Watch a valuable tool in your daily workflow. When you need alternatives, understanding how Sencha Cmd manages these details can help streamline your daily process. Let us know what you think and enjoy the new color picker component.

P.S. You can test out the color picker here.