Finding those pesky little bugs (ex Flex Developer)

Slowly (ok, not that slow, I am pretty excited about getting up to speed ASAP!) transitioning from Flex (ColdFusion / MSSQL) to ExtJS. (still using CF and MSSQL, am impressed with the performance so far!). However, I am sort of spoiled with a compiler that will catch little typos:

All of a sudden, after some changes, my app was acting strange (sort of worked.. but not really). There were NO errors on the console, but I tracked it down to the following statement:

Ext.ComponentQuery.query('#myTabPanel').setDisable(1);

(Yes, for those with eagle eyes, I missed the 'd' at the end). It took me a while, with my old, tired eyes.

Is there any way (besides Firebug, Chrome, etc.) to find these errors?

I am using Architect. Would this be better if I was using eclipse with the plugins?

Your hitting one of my favorite 'rant' subjects. Architect is a code generating GUI tool and not a real javascript editor. Trying to turn it into one instead of focussing on its core business, creating powerful GUIs is in my opinion a big mistake. There are fare better javascript editors like Webstorm, Aptana, Eclipse and even MS Visual Studio.

However, one of the big problems with Architect is that, although they claim it, it is difficult, but certainly not impossible, to create your GUI in Architect and do any logic, i.e. controller code, in a real javascript editor. You have to override classes to do this and have to be aware that Architect may overwrite your code anyway.

Therefore, there should be at least a refresh button in Architect that enables refresh from external written code.

So, in short, separate the GUI code from handwritten code and do the handwritten code in an external javascript editor.

as an Ex-Flex developer, I was impressed with their plug in. You could instantly switch between the code and design mode (and in the design mode, it had the context-sensitive properties panels which was a HUGE timesaver for those of us who did not know ALL of the 100's of available properties, methods, events, etc.). I am not sure why the good folks @ Sencha didn't go that route. But, what do I know???

To a human reader it becomes pretty easy to see that you are returning an Ext.tab.Panel. A tool could only possibly know that you are returning a Ext.Component. Luckily setDisabled is part of component and could have been provided by autocomplete (but only with specific knowledge that the framework returned an array of Ext.Component's from a Ext.ComponentQuery.query

With this knowledge it's possible that we could tell you that you are trying to call a setDisabled method on an array. While we can assume this is probably incorrect it is completely possible that you could add a method to an array.

As you can see we've added a method called setDisabled to all arrays. JavaScript is such a dynamic language that this is possible (albeit not recommended). In the past it was very common to add functions to the prototype of a class (for array things like pluck, sum, unique, etc). This has generally been regarded as a bad practice and you'll note that Ext JS and Sencha Touch have moved these helper functions into the Ext.Array class.

First of all there was an syntactical error by omitting the d from setDisabled, then there was the probable error of calling a method on an array that probably doesn't exist. Then a component query could return just about anything. And my '#myTabPanel' could just as well return:

Code:

Ext.create('Ext.window.Window', { itemId: 'myTabPanel' });

Therefore, you have to unit test these things, there is no way around it. And that is yet another caveat with Architect, people start dragging components on the canvas creating functions, introducing even plain business logic into it, bad things happen. The general setup MVC setup provides in essence a very clean distinction between pure GUI generating code and GUI logic code. I feel perfectly comfortable with Architect generating the views and even stores and models. But for the rest I like to start with a plain old unit test.

I agree with your point that making JS tooling understand every possible construct in the general case is not possible or at least prohibitively hard. However, I want to say that JS tooling should be able to work better and handle most cases if extra metadata is provided.

This should work. Using JSDoc / JSDuck annotations on local variables seems a decent trade off. There's no size penalty in the end product since builds should strip away the comments anyway.

The Sencha Eclipse plugin actually supports some annotations, although unfortunately not @type the last time I checked.

Originally Posted by aconran

...
It's all a question of flex's optional static typing vs JavaScripts dynamic typing.
To further your specific example, let me explain a bit further as you've pointed out a good place where JS Tooling cannot provide all of the type info you want.

To a human reader it becomes pretty easy to see that you are returning an Ext.tab.Panel. A tool could only possibly know that you are returning a Ext.Component. Luckily setDisabled is part of component and could have been provided by autocomplete (but only with specific knowledge that the framework returned an array of Ext.Component's from a Ext.ComponentQuery.query
...