1. #1
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Connecticut
    Posts
    510
    Answers
    7
    Vote Rating
    36
    blomasky has a spectacular aura about blomasky has a spectacular aura about

      0  

    Default Unanswered: Finding those pesky little bugs (ex Flex Developer)

    Unanswered: 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?

    Thanks

    Bruce

  2. #2
    Ext Premium Member halcwb's Avatar
    Join Date
    Mar 2010
    Location
    Rotterdam
    Posts
    379
    Answers
    10
    Vote Rating
    39
    halcwb has a spectacular aura about halcwb has a spectacular aura about

      0  

    Default


    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.

  3. #3
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Connecticut
    Posts
    510
    Answers
    7
    Vote Rating
    36
    blomasky has a spectacular aura about blomasky has a spectacular aura about

      0  

    Default


    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???

  4. #4
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,165
    Answers
    60
    Vote Rating
    119
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    It's all a question of flex's optional static typing vs JavaScripts dynamic typing. There are several flame wars on this topic including Java vs JavaScript, C# vs JavaScript, TypeScript vs JavaScript, Dart vs JavaScript.

    I will say that we are overhauling the code editing experience that will be out in our next 3.0 beta. You will see some of the things that you want.


    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.

    Your original code was:
    Code:
    Ext.ComponentQuery.query('#myTabPanel').setDisable(1);
    Let's break that down:
    Code:
    var component = Ext.ComponentQuery.query('#myTabPanel');
    component.setDisable(1);
    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.

    Try to run the following code:
    Code:
    Array.prototype.setDisabled=function(){console.log('hi');}
    var abc = [1,2,3];
    abc.setDisabled(true);
    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.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  5. #5
    Ext Premium Member halcwb's Avatar
    Join Date
    Mar 2010
    Location
    Rotterdam
    Posts
    379
    Answers
    10
    Vote Rating
    39
    halcwb has a spectacular aura about halcwb has a spectacular aura about

      0  

    Default


    This triggers yet another 'rant' of mine;-)

    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.

    So I would say
    Code:
    it('should have a setDisabled method', function () {
        var component = Ext.ComponentQuery.query('#myTabPanel');
        expect(component.setDisabled).toBeDefined();
    });
    And the test would fail. If later on I go about and start messing up my itemId, the test would catch the resulting error.

    Unit testing, not being able to properly unit test your code is a code smell! I would like Architect to better support separation of code that needs unit testing and pure Ext generated code.

  6. #6
    Sencha Premium Member
    Join Date
    Jan 2009
    Posts
    318
    Answers
    12
    Vote Rating
    47
    firefoxSafari has a spectacular aura about firefoxSafari has a spectacular aura about firefoxSafari has a spectacular aura about

      0  

    Default


    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.

    Code:
    /**
     * @type {Ext.tab.Panel}
     */
    var component = Ext.ComponentQuery.query('#myTabPanel');
    component.setDisable(1);
    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.

    Quote Originally Posted by aconran View Post
    ...
    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.

    Your original code was:
    Code:
    Ext.ComponentQuery.query('#myTabPanel').setDisable(1);
    Let's break that down:
    Code:
    var component = Ext.ComponentQuery.query('#myTabPanel');
    component.setDisable(1);
    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
    ...