20 rules to follow when you start working with EXT JS & Sencha Touch

This article is a translation of an article from the blog www.swarmonline.com with some of my additions.

When learning new technologies, developers often make the same mistakes as other people and follow the same bad techniques.

In this article, we have compiled a list of some of the things that we recommend you do when you start working with Ext JS (even if you are a veteran of development, you can still learn something new!). These things went through our experience, through viewing and answering the same questions on the forums. This is the most common of the best programming techniques.
')
I hope this helps you to jump a few steps in learning Ext JS and help you avoid standard mistakes.

Although we are obviously talking only about Ext JS, most (if not all) clauses can be applied to Sencha Touch, since the framework structure is similar.

Avoid using Ext.getCmp

Do not be tempted to give all your components ids and use Ext.getCmp to find them again. If the structure of your application is correct and the principles of object-oriented code design are followed, you should have no problems accessing your components when they are needed.

Useful links:
Writing a Big Application by Saki
Component Communication Example by Saki

Avoid using owneCt properties

Do not rely on the ownerCt property to get the parent element. If you are trying to get access to the parent in the component code, then most likely this code should be in the parent itself. This is very similar to using Ext.getCmp (described above), so be sure to read the indicated links.

Do not framing panels.

A very common mistake for newbies is creating framing panels. Think about the interface structure and remember that components such as the Form Panel , the Grid Panel and the Tab Panel are inherited from the Panel class, and therefore there is no need to wrap them with another panel. They can be placed in the same place where their common ancestor is and configured with the same properties.

Be careful with the spaghetti code (scope).

Do not declare all your components in a single file or inline (it is inline ) - this will become a nightmare when debugging and your scope will be everywhere. Make it all easier by expanding component declarations across different files, as well as extend the base classes to add your own configuration, methods, and behaviors. So you can simply instantiate your components anywhere, they will turn out beautiful and loosely coupled.

Translator's note.
Very often there is a desire to declare components nested using xtype

Ext.define('App.window.CreateMan', { extend : 'Ext.panel.Panel', require : ['App.models.Man'], items : [{ xtype : 'textfield', label : '' }, { xtype : 'textfield', label : '' }, { xtype : 'button', text : '', handler : this.saveData } ], saveData() { //... } }); 

It looks quite bearable. A little later you will add another field to enter middle names. Then the drop-down list with the choice of citizenship. And connect plugins to the list ... As a result, get a bunch of nested code. In the projects that I got, nesting reached fourteen levels. In the case when I had to debug such code, I first did a thorough refactoring.
It is important to catch the moment when it is worth putting elements into the initComponent method .

 Ext.define('App.window.CreateMan', { extend : 'Ext.panel.Panel', require : ['App.models.Man'], initComponent : function () { this.callParent(arguments); var superPanel = Ext.create('App.util.SuperPanel', //    ); var saveButton = { xtype : 'button', text : '', handler : this.saveData, //    }; items = [{ xtype : 'textfield', label : '' }, { xtype : 'textfield', label : '' }, superPanel, saveButton ]; }, saveData() { //... } }); 

If you don't want to expand base classes all the time, you can use Factory Methods as an alternative.

Be sure to use namespaces.

Again: organization is our everything. Using the built-in capabilities of the Ext JS namespaces will allow you to organize components and classes, so that in the future it will be easy to navigate them. Most likely, you will want to divide the namespaces by functional modules, for example, the MyApp.Users namespace for all code that works with users. I also like to create a directory structure corresponding to namespaces. Then it is always easy to search for the desired module.

Translator's note.
Ext JS 4 also implements automatic loading, which requires matching namespaces and directories. This allows you to call the Ext.create method ('App.modules.User') even if the App.modules.User class is not loaded yet. Ext will take care of the download itself.
More here

Proper use of get / set methods and static variables

Do not be tempted to delve into the collection of component elements to get a link to a button or panel using syntax like ' comp.get (0) ' or ' comp.getTopToolbar (). Get (1) '. If you ever add a new item to such a collection, links to such items will be incorrect. In large applications, this will be a huge challenge in catching bugs.

To save yourself from unnecessary problems, you can create a Get method for the necessary components that will dig into the collection. When you add new components, you will update only this method. If you are not in favor of lazy instantiation (lazy instantiation), you can define the necessary buttons and elements as members of the class and thus will not need to make any changes when added to the collection.

Translator's note.
To add a descendant as a member of a class, you can simply transfer it from the config ...

 Ext.define('App.window.CreateMan', { extend : 'Ext.panel.Panel', items : [{ xtype : 'panel', //    } ] // ... }); 

... to the initComponent method

 Ext.define('App.window.CreateMan', { extend : 'Ext.panel.Panel', initComponent : function () { this.childPanel = Ext.create(/* ... */ ) } // ... }); 

This way you will get a reference to the child directly in the class object.

Create xtypes neatly

Specify xtype as the name of your class, including namespace. This way you can easily track the actual class definition.

Reuse code

If you find yourself writing the same code again and again (for example, masking elements when loading, answers, errors, and so on) then wrap the code in a function to use it later. So you save yourself time and effort - you will thank yourself when you decide to change this piece of code and you will not need to redo hundreds of copies of it.

Do not create nested functions.

Do not declare a function inside a function (inside a function ... inside a function ...). You might think that you are creating a reusable code, but you are only creating nightmarish scopes and organization. To accompany such a code is a controversial pleasure, so think about your colleagues who will have to debug it.

Learn to use FireBug

... or WebKit developer tools. Make sure you use all browser tools, such as FireBug, to debug JavaScript and to understand what HTML and CSS code the framework generates. At the initial stage of the study it is very easy to forget that the whole Ext generates page layout, but the tools will allow you to understand what is happening inside the black box. If you learn how to use these tools and how to debug JS efficiently, you will save yourself a huge amount of time.

Turn the framework into a White Box!

As Evan said, “Do not be afraid of the source code.” Use your skills in working with FireBug to get inside the Ext JS framework, rather than stepping over the challenges of its methods in the debugger. It is incredible how much you can find out and how easily you can solve a problem by going inside the framework method, not to mention getting rid of hours of stress in trying to figure out what the problem is.

Always keep documentation open.

Documentation is your best friend. It should be your first stop when you run into problems or are looking for something new. It is well thought out and easy to navigate, so use it!

Translator's note.
It is very convenient to create an application with documentation in chrome, as its interface uses tabs.

Debugging stages

What should be the actions when solving the problem:

• Check your code (it’s very easy to make spelling mistakes in settings, skip commands, and so on).
  

  Note: anyone who uses notepad ++ like me has a great solution for checking JS for errors and warnings

• Refer to the documentation (you may have missed some options in the configuration)
• Look at the source code during debugging (make a breakpoint in front of the place where the error occurs and see what goes wrong. You will surely find a missing config or a call for something that has not yet been instantiated)
• Search the forum (most likely someone has already encountered a similar problem and asked about it)
• Search the entire web (if the forum could not help, perhaps the answer is on the web)
• Create a topic on the forum (if you have not found a solution, then describe the problem on the forum as fully as possible so that it would be easier for people to help)

Build the interface gradually.

It is very easy to go into work and create half a dozen components, and then open it in a browser and see the result. If it does not work, then sometimes it is extremely difficult to move in the opposite direction in an attempt to find the culprit. We propose to create one component at a time and move on after making sure that everything works. For example, if you want to create a DataGrid, adding elements to which will be animated, then create an addition first and then deal with the animation. If you try to do everything at once, most likely something will go wrong.

Minimize and package (GZip) your end code

We recommend placing all components in separate files. This means that you will receive a bunch of requests, so make sure that all the scripts are stitched into one file. Then you minimize the number of requests and compress code size.
After that, make sure your server supports gzip for your scripts. This will reduce the size of the loaded code by 70%!

Do not modify the code of the framework!

Dig into it, read it, test it, study it, but NEVER modify it. If you start editing in the core of the library, no matter in JS or CSS, you will place a time bomb in your application. When you update the framework to the new version and all changes are lost, you will find out for a long time how everything works.
If you want to change the behavior or type of framework, do it through redefining classes (these can be JS or CSS classes) or methods placed in separate files. Subsequently, you can easily remove these classes and methods and easily track them when it comes to updating the framework.

Use plugins and custom extensions

If you want to make a component that solves the distributed task, it is quite possible that someone has already released it as a plug-in or extension. Spend some time searching the forums and on the web before writing a component from scratch (although if you have time, this is a great way to learn)

Define common elements in one place

It is very convenient to define in the same config file all your variables, namespaces and other constructions that are used throughout the program. This makes it much easier to change them and encourages reuse.

Consider using Ext.Direct

Ext.Direct is a great feature of Ext JS, which we highly recommend using from the very beginning. It gives such advantages as speed increase, reduction of code and simplification of interaction with the server. If you are considering using it in the future, don't! Start using it right now. It is much easier to implement from the very beginning, rather than bring it into running applications. You will thank us in the long term.

Test in all browsers!

Although Ext JS took care of almost complete cross-browser compatibility, always test all browsers, especially IE. As always, some CSS rules do not work correctly in IE, and extra commas will break your application.