Friday, September 6, 2013

Efficient coding style in ExtJs: Volume 3

.....being continued from "Efficient coding style in ExtJs: Volume 2"

Very important links related to this post:

17) Proper use of parseInt(): Use parseInt() with proper redix to avoid some unwanted result. E.g.

alert(parseInt("8")); // "Will print 8"
alert(parseInt("08")); // "Will print 0"
alert(parseInt("08,10")); // "Will print 8"
If we use parseInt(“08”), it gives octal value of 08.

So always remember to use second parameter i.e. redix to define the type of number i.e. whether it is decimal, octal or hexadecimal.

18) Be careful about function hoisting: This problem is similar as discussed above in case of variable hoisting. The only difference comes when we use function declaration instead of anonymous function. In case of function declaration, function definition also gets hoisted not only its declaration and improper handling of this will give some unwanted result. E.g.

// antipattern
// for illustration only
// global functions
function foo() {
alert('global foo');
}
function bar() {
alert('global bar');
}
function hoistMe() {
console.log(typeof foo); // "function"
console.log(typeof bar); // "undefined"
foo(); // "local foo"
bar(); // TypeError: bar is not a function
// function declaration:
// variable 'foo' and its implementation both get hoisted
function foo() {
alert('local foo');
}
// function expression:
// only variable 'bar' gets hoisted
// not the implementation
var bar = function () {
alert('local bar');
};
}
hoistMe();

In this example you see that, just like with normal variables, the mere presence of foo and bar anywhere in the hoistMe() function moves them to the top, overwriting the global foo and bar. The difference is that local foo()’s definition is hoisted to the top and works fine; although it’s defined later. The definition of bar() is not hoisted, only its declaration. That’s why until the code execution reaches bar()’s definition, it’s undefined and not usable as a function (while still preventing the global bar() from being “seen” in the scope chain).

19) Adding a property to global namespace: While adding a property to a global name space or global object we should be careful that this may already exist, and we could be overwriting them. Therefore, before adding a property or creating a namespace, it’s best to check first that it doesn’t already exist. E.g.

// unsafe and antipattern
var MYAPP = {};
// better
if (typeof MYAPP === "undefined") {
var MYAPP = {};
}
// or shorter
var MYAPP = MYAPP || {};

To avoid always writing this boilerplate code when creating any member in global name space, we can create some reusable code where we can pass the object to be created and that code will perform above validation and can add or discard our object.

20) Utilize JsLint: JSLint takes a JavaScript source and scans it. If it finds a problem, it returns a message describing the problem and an approximate location within the source. The problem is not necessarily a syntax error, although it often is. JSLint looks at some style conventions as well as structural problems. It does not prove that your program is correct. It just provides another set of eyes to help spot problems. We have to simply paste our script, and it’ll quickly scan for any noticeable issues and errors in our code.
URL: http://www.jslint.com/

21) Avoid with() statement: At first glance, "With" statements seem like a smart idea. The basic concept is that it can be used to provide a shorthand for accessing deeply nested objects. E.g.

with (being.person.man.bodyparts) {  
                                arms = true;  
                                legs = true;  
                 }

Instead of
being.person.man.bodyparts.arms = true;  
                being.person.man.bodyparts.legs= true;

Unfortunately, after some testing, it was found that they "behave very badly when setting new members." Instead, we should use var.
                                 var o = being.person.man.bodyparts;  
                                o.arms = true;  
                o.legs = true;

22) Use ExtJs builtin functions to add or remove elements from Extjs components: To add some objects to an ExtJs container, following code should not be used:

componentObj.items.items[0] = newObject;

Problem in this code:  If this code is used to add something in a container, all built-in tasks of ExtJs are not performed at the time of addition of an object to a container and it may cause some problems.
Solution: add() function of a container object should be used and similarly other built-in functions of a component should be used for corresponding tasks.

23) To retrieve components from ExtJs components: To retrieve an object from  ExtJs component, following code should not be used:

var anObj = componentObject.items.items[0].items.items[1];

Problem: If a new layer, say a panel or a container, is included in the above hierarchy by someone, the whole hierarchy will get disturbed and we will get wrong result.
Solution: We can use Ext.getCmp(componentId) or queryById(componentId) instead of traversing long hierarchy. Although it is little bit slower than traversing hierarchy, yet in this case the hierarchy problem, as discussed above, will not come.

24) Write more readable and debuggable and reusable code: While writing code, developer should create small meaningful classes and functions. Don't try to put large number of lines in a single block. Try to keep code block small so that it can be easily reused and will be more readable.

No comments:

Post a Comment

Please provide your precious comments and suggestion