20 Things To Avoid/Do When Getting Started With Ext JS & Sencha Touch

20 Things To Avoid/Do When Getting Started With Ext JS & Sencha Touch

When learning a new topic people often make the same mistakes and follow the same bad practices as each other. It usually follows by them realising that what they’ve been doing for a few days/weeks/months is a bad way of doing it and wondering how they didn’t realise earlier.

In this article we’ve put together a (non-exhausted!) list of a few of the things we’ve picked up and things we recommend you do when starting out with Ext JS (hey, even you veteran developers might learn something new!). These things have come up through our own experience; through seeing and replying to the same issues on the forums again and again; and just general good programming practices.

Hopefully this will jump you a few rungs up the ladder of learning Ext JS and help you avoid falling into the usual traps!

Although we are only explicitly talking about Ext JS, most, if not all, of these tips can be applied to Sencha Touch as the structure of the framework is so similar.

Avoid using Ext.getCmp

Don’t be tempted to give all your components IDs and then use Ext.getCmp to find them again. If you structure your applications correctly and apply the principles of Object Oriented (OO) design properly then you shouldn’t have a problem getting access to your components when you need them.

Useful References:

Writing a Big Application by Saki

Component Communication Example by Saki

Avoid Using the ownerCt Property

Don’t rely on the ownerCt property to get a component’s parent. Chances are if you’re wanting to access the component’s parent within its code then the code shouldn’t be there. The code should likely be in the parent itself. This is a similar thing to using Ext.getCmp (above) so make sure you read the linked articles!

Do Not Overnest Components

A hugely common mistake found in new Ext JS developers’ code is the overnesting of Panels. Think carefully about your structure and remember that components such as FormPanels, GridPanels and TabPanels all extend the Panel class so don’t need to be wrapped in another Panel. They can be placed wherever their more generic parents can and be configured with the same options.

Be Careful of Spaghetti Code/Scope

Don’t define all your components in one big file or all inline – it will be a nightmare to debug and your scope will be all over the place. Make things easy and split each component definition into its own file and extend the base class to add your configuration and extra methods and behaviours. This way you can simply instantiate these components where you need them keeping things nice and tidy and loosely coupled.

If you don’t want to extend base classes all the time then using Factory Methods is another option.

Make Sure You Use Namespaces

Again, its all about organisation. Utilise the inbuilt namespace capabilities of Ext JS to organise your components and classes so its easy to navigate later. Typically you would want to do this by functional module, for example, MyApp.Users for all the User management code. I like to mirror this namespace structure with the folder structure so everything is dead easy to find.

Use Get/Set Methods or Static References

Don’t be tempted to delve into a component’s items or toolbar collections to get a reference to a particular button or panel using the ‘comp.get(0)’ or comp.getTopToolbar().get(1)’ syntax. If you ever add items to these collections the references will be broken and you will have to track them down. In a big application this becomes a mammoth task which will introduce bugs.

Save yourself some hassle and, in the extended class, create a get method for the necessary components, which delves into the collection, so when you do add more items you know there is only one method to be updated. Or, if you aren’t concerned about lazy instantiation, define your buttons and items as class variables and reference them that way so you won’t need to make any updates when new items are added.

Name Your xtypes Carefully

Name your xtypes the same as your class, including namespaces, so you can track down the actual class definition very easily.

Reuse Your Code

If you find yourself writing the same code again and again (think masking elements while loading, response/error handling code etc) then wrap that stuff in a function in a way that makes it generic and reuse it. Save yourself the time, effort and RSI – you’ll thank yourself when you decide to change it and have to change hundreds of copies.

Try Not to Nest Functions

Don’t define functions within functions (within functions…within functions…). You may think your doing some good code reuse but your just creating a scoping and organisation nightmare. Trying to follow that sort of nesting is not pleasant, so spare a thought for your co-workers who might have to debug it.

Learn how to use FireBug

…or WebKit’s Developer tools. Make sure you install and use an in-browser tool like FireBug to debug your Javascript and to explore what HTML and CSS the framework is creating. It’s easy to forget that, at the ground level, all Ext is doing is generating markup and these tools will give you an insight into what’s happening in the black box. If you learn how to use these tools properly and how to debug your JS effectively you will save yourself a huge amount of time.

Not to mention everything else it can do – Monitor AJAX requests, DOM exploration, real-time CSS changes etc etc

Make it a White Box!

As Evan says “Don’t be afraid of the source code!”. Use your new found FireBug knowledge to break into the Ext JS Framework rather than always stepping over those calls. It’s incredible how much you can learn and how easily you can find a problem by stepping into a framework method, not to mention the hours of stress trying to figure out a problem.

Always Have the Docs Open

The API documentation is your best friend – it should be your first port of call when running into problems or when trying something new. Intellisense for Ext JS isn’t quite up to the standards of Visual Studio for .NET so we can’t get away with being so lazy – the docs are the answer to this. They are well laid out and easy to navigate, so make use of them!

Debugging Chain

How you should go about fixing a problem…

Check your Code (it’s easy to misspell config options, miss commas etc)

Refer to the Documentation (you might be missing a related config option)

Step into the Framework’s Source Code (break into the code around the error and try to see what’s going wrong, you’ll likely discover a config option you’ve missed, or realise something you expected to be there isn’t instantiated yet)

Search the Forum (it’s almost a guarantee that someone will have had the same problem and posted a question about it)

Search the wider WWW (if the forum can’t help the wider web might be able to)

Post on the Forum (if you still can’t find the resolution, create a new thread with as much detail about the problem as you can – make it easy for people to help you)

Build it Up Gradually

It’s all too easy to get too excited about a project and dive right in and create half a dozen components and then open the browser and give it a try. If it doesn’t work it can be very difficult to move backwards trying to find the culprit. We suggest creating things a stage at a time and gradually build it up once you’re sure each thing works as you want. For example, if you’re trying to create DataView that allows new items to be added to it with the new item being animated in – get the new items adding first then move on to animating it. If you try to do everything at once something’s likely to go wrong.

Minify & GZip your Production Code

We recommend separating out all of your components into their own files. This means you’re going to have a bucket load of requests to download them all so make sure you minify your scripts into a single file to minimise the number of requests and to compress the file size.

Once you’ve done this make sure your server is set up to GZip your scripts. This can reduce the download size by about 70%!

Don’t Edit the Framework Code

Yes, delve into it, read it, test it, learn from it – but don’t edit it! If you start making changes to the core library, whether it is the JS or CSS, you are planting a ticking time-bomb into your application. When you come to upgrade to a newer version all those changes will be lost and you will have to traipse through trying to figure out where things are broken!

If you want to alter the behaviour/look of the framework then go for it but do it by overriding the class (be it a JS class or a CSS class) or method in a seperate script file. By doing this you can remove it if necessary and keep track of it when it comes to reviewing those changes when new versions are released.

Use Plugins and User Extensions

If you are wanting a component to do something that is fairly generic and a common functional requirement it is likely that someone has already coded it and released it as a Plugin or an Extension. Take some time before coding it from scratch (unless you have the time – it’s a great way to learn!) to search the forums and the web for a pre-made solution.

Define Generic Items in a Central Location

It’s handy to define all your variables, namespaces etc that are used application wide in a single config file. This keeps everything in one place, makes values easier to update and encourages reuse.

Consider Using Ext Direct

Ext.Direct is a brilliant feature of the Ext JS Framework and we highly recommend you implement it from the outset. It has various advantages including increasing speed, reducing code and a simplified way of interacting with your server. If you think you might consider it in the future, don’t, consider it now. It’s far easier to implement from the outset than convert everything over. You’ll thank us in the long run!

Test on All Browsers!

Although Ext JS takes care of 99% of cross browser issues always remember to test your application across all the browsers – especially IE! The usual IE CSS issues are common when creating custom data views and JS errors such as rogue commas will bring your application to its knees.

If you have any of your own tips or best practises please leave us a comment and we’ll add them to the list!