JavaScript. ExtJS. Code Manageability. These three words are always posed our way from clients as we embark on new project development and, in particular, when Etelligence is brought in on ExtJS project salvage engagements.

Here are our Top 5 pointers to keeping your large Sencha ExtJS applications maintainable, organized, and consistent.

1.) Application Folder Structure

The way you organize your ExtJS application will go a long way. Typically in large scale development, a distributed team of developers works cohesively in the delivery of the project. As is usually the case, each developer has a tendency to follow the folder structure that already has been put in place. This is why from the advent of the project a logical folder structure needs to be established and enforced.

In ExtJS 4.x a standard MVC package structure was introduced (model, view, store, controller). Most folks follow this structure to a tee, which is great, but by folder structure we are referring to a more granular “subfolder” structure.

Organize by Application Flow or ExtJS Component? Either approach works. As long as a new team member, at a quick glance, can understand which components are residing where, then you know a good structure is in place.

The approach our team takes is to namespace at the component level, and further namespace by application flow when needed. For example:

MyApp.view.grid.brokerage.Securities
MyApp.view.grid.Dynamic
MyApp.view.container.Portal
MyApp.view.container.brokerage.Tracker

2.) XTYPE Naming Convention

As an application grows and usage of xtypes increases, it’s incredibly useful to be able to see an xtype and know exactly where the class is. We have worked on large applications where seeing an xtype: “securitiesgrid” being used doesn’t really help in determining where the actual class resides. Many times we have had to end up doing clunky searches to see which class an xtype is registered to.

Our recommendation is to follow the Java packaging approach, but to use underscores in place of dots. In ExtJS 4.x using dots in the xtype name led to some inconsistent behavior.

For example:

Ext.define("MyApp.view.grid.brokerage.Securities", {
  extend: "Ext.grid.Panel",
  alias: "widget.myapp_grid_brokerage_securities",

  ........
});

Folder Structure:

/app
  /controller
  /model
  /store
  /view
    /grid
      /brokerage
        Securities.js

3.) Class Names

Class names should be named after their logical purpose and should not contain the component type in the name. If the component is already in a “grid” folder, there is no point in name the component “SecuritiesGrid”.

Poor Practice:

MyApp.view.grid.brokerage.SecuritiesGrid
MyApp.view.container.PortalContainer

Good Practice:

MyApp.view.grid.brokerage.Securities
MyApp.view.container.Portal

4.) Constants

Use a Constants file. Not just for common text Strings, but also for service action url’s. Avoid hardcoding the action url in the Store’s proxy. This will particularly help during parallel development when a server-side action is not ready. By setting the url in a common.Constants class the url’s can be centrally updated to point to either a stubbed JSON file or an actual action.

5.) Grid overkill

Many times we encounter a project that has over 30 grid extensions. All that these extensions do is set Column definitions, load, and show tabular data. Most of these can be replaced one single Dynamic grid that fetches column and model definitions from the server. This drastically trims the codebase in having to maintain only one grid class. In our projects we almost always create one MyApp.view.grid.Dynamic component. As needed, we create separate grid extensions that require some very specific behavior. This also avoids bloating the Dynamic shared component.