[CLOSED] Possible breaking change in 3.x to 4.x upgrade

Z · May 25, 2017, 3:13 AM

Support,
See example below. THe store is simple id/description so i didnt bother to include it.

I am well aware of the bug that we accidentally called expand on the Store instead of the Combo. However, this worked (without a JS error) in 3.x. By worked, i mean it didnt crash (but didnt expand either).

We just upgraded to v4 and this now throws an JS error.

While a bug (in my code), it is a breaking change.

Thanks,
/Z

                    <ext:ComboBox ID="ComboBox1" 
                                            runat="server"
                                            DisplayField="description"
                                            HideLabel="true"
                                            ValueField="id"
                                            QueryMode="Local"
                                            StoreID="Store1"
                                            EmptyText="Select ...">
                                            
                                            <Triggers>
                                                <ext:FieldTrigger Icon="Clear" Qtip="Remove selected" />
                                            </Triggers>
                                            <ListConfig LoadingText="Loading..." />
                                            <Listeners>
                                                <Focus Handler="#{Store1}.load();#{Store1}.expand();" Single="true" />
                                                <TriggerClick Handler="this.clearValue();" />
                                            </Listeners>
                                        </ext:ComboBox>

**fabricio.murta** · May 25, 2017, 3:24 AM

Hello @Z!

Would you be so kind as to provide the fully runnable test case so we can reproduce this on our end? Clear steps like "1. click here", "2. click there", "3. you should see this but see that" would help us understand what's going on.

But by your description, it is hard to think on a breaking change over something that didn't work on to something that does not work and throws an error message... But there's, yes, the nuisance part.

Or in different words "something that was not supported" to become "not supported and throwing error messages".

Well, if we can try and run the code maybe we can understand better what's going on, and we appreciate your report!

Z · May 25, 2017, 3:40 AM

Load and then click the combo. i recall this doesnt crash on 3.x

<%@ Page Language="C#" %>


<!DOCTYPE html>




<html>
<head id="Head1" runat="server">
    <link href="/resources/css/examples.css" rel="stylesheet" />    




        <style type="text/css">
        .red-text {
            color     : red;
            font-size : large;
        }
    </style>


    <script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!X.IsAjaxRequest)
        {
            this.Test1.Store.Primary.DataSource = new object[]
            {
                new object[] { 1, "test1" },
                new object[] { 2, "test2" },
                new object[] { 3, "test3" }
            };


            this.Test1.Store.Primary.DataBind();
        }
    }
</script>


    <script>
        var runMe = function () {
            App.TESTSETET.show();
        };
    </script>
</head>
<body>
    <form id="Form1" runat="server">
        <ext:ResourceManager ID="ResourceManager1" runat="server">
            <Listeners>
                <DocumentReady Handler="runMe()" />
            </Listeners>
        </ext:ResourceManager>




                




    <ext:Window 
        ID="TESTSETET" 
        runat="server" 
        Icon="ApplicationFormAdd" 
        Width="500" 
        Hidden="true" 
        Modal="true"
        Layout="FitLayout"
        Title="TEST">
        <Items>
            <ext:FormPanel
                ID="FormTEST" 
                runat="server" 
                Layout="VBoxLayout"
                BodyPadding="5"
                >
                <Items>
                    <ext:ComboBox ID="Test1" 
                        runat="server"
                        DisplayField="description"
                        HideLabel="true"
                        ValueField="id"
                        QueryMode="Local"
                        EmptyText="Select ...">
                        <Store>
                            <ext:Store ID="Store1" runat="server" >
                                <Model>
                                    <ext:Model ID="Model1" IDProperty="id" runat="server">
                                        <Fields>
                                            <ext:ModelField Name="id" />
                                            <ext:ModelField Name="description" />
                                        </Fields>
                                    </ext:Model>
                                </Model>
                                <Sorters>
                                    <ext:DataSorter Property="description" Direction="ASC" />
                                </Sorters>
                            </ext:Store>
                        </Store>                                            
                        <Triggers>
                            <ext:FieldTrigger Icon="Clear" Qtip="Remove selected" />
                        </Triggers>
                        <ListConfig LoadingText="Loading..." />
                        <Listeners>
                            <Focus Handler="#{Store1}.load();#{Store1}.expand();" Single="true" />
                            <TriggerClick Handler="this.clearValue();" />
                        </Listeners>
                    </ext:ComboBox>


                </Items>
            </ext:FormPanel>
        </Items>
    </ext:Window>
    </form>
</body>
</html>

**fabricio.murta** · May 25, 2017, 4:55 AM

Hello @Z!

Thanks for the test case. I am trying it here, and it throws a javascript exception on both v3 and v4.

If I don't set the debugging tools to stop by the exception, I see it pops up on console and nothing more happens.

The only odd thing I noticed here was, while playing on v3, is that if I click the combo box by its trigger button (to shown the available options therein), the error only stops in chrome if I check debugging tools' "pause on caught exceptions".

But if I click the combo box on its body (not trigger), both versions get to be stopped by the exception even with "pause on caught exceptions" unchecked.

So in summary, assuming the focus event handler of a combo box has a runtime "type error":
a. by clicking the combo box from the trigger button, an "Uncaught type error" is raised
a1. v3: chrome does NOT triggers the debugger unless "pause on caught exceptions" is checked
a2. v4: chrome triggers the debugger if "pause on exceptions" is enabled

b. by clicking the combo box from anywhere in the text field part, an "Uncaught type error" is raised
b1. v3: chrome triggers the debugger if "pause on exceptions" is enabled
b2. v4: chrome triggers the debugger if "pause on exceptions" is enabled

By that I understand that this really a breaking change, but that involves a behavior and situation that was neither documented nor supported. I mean, the suppressed error raising by the combo box in situation a1 above was not something supposed to happen and should not be relied in, very similar to when we use an override which accesses private resources in classes (or private classes). It can work on a given version but may change without further notice.

In practical terms, and the reason I believe this breaking change was introduced, is related to changes in event handling. For example, we had an issue with radio buttons which are now the 'change' event is called "earlier", making the client see the old value from the "change". If we relied on accessing App.MyComponent.getValue() instead of the event's newValue or oldValue, it happened that version 4.1.0 was getting the new value already, whilst 4.2.0 was getting still the old value (the event was then called a bit earlier in the new version). But we couldn't really call this a breaking change as one was not supposed to rely on the component's current value during the change event (where the component is about to get -- or just got -- the new value.

At least, this kind of breaking changes are not published by Sencha, can we can but rely on their changelog every time we upgrade.

Sorry for the very long reply, what I'm trying to say here is that I agree that it is a breaking change, but not something one can just track down between versions, particularly major versions. As there's no place stating that an error during focus event of a combo box is clicked should be "caught" if the combo box's trigger is clicked, or the current value of a radio button during the change event call (whilst the latter has both newValue and oldValue parameters available on the event scope).

But that was a very interesting catch! Unfortunately, one I'm afraid we can't address. After all, that's a migration from v3 to v4.

I hope you understand!

Z · May 25, 2017, 5:30 AM

I didnt expect you to fix it :)

I corrected my code.

i expected you to just document it as a "BREAKING CHANGE" in your next readme release notes.

/Z

**fabricio.murta** · May 25, 2017, 7:25 AM

Hello @z!

When a breaking change is server-side, from Ext.NET WebForms or MVC/razor or C#, it is easy for us to detect and log the breaking change. We can know if a change is going to break the build process from Visual Studio. For example if we change an Enum, removing a previously supported option, that could potentially break an application that was referencing that enum value.

But when it is inherent and exclusive to client-side interatction, we are but limited to the release notes we can see from Sencha. When talking client-side, the change event firing before or after a component has actually changed for example.

Well, unless we actually trigger the issue, like you did, of course! :)
But when it happens after the release, it is still an issue.

In fact, in this case, the error suppression when the click is in the trigger not the field, was something that happened "by accident" I dare say. Sencha tries to keep track of their changes (and breaking ones) for what they documented, as if their docs were actual "contracts" for the use case scenarios. Some could see that as a bug that was resolved in the recent releases.

Thread: [CLOSED] Possible breaking change in 3.x to 4.x upgrade

Thread Tools

Search Thread

Display

[CLOSED] Possible breaking change in 3.x to 4.x upgrade

Similar Threads

[CLOSED] ModelField' UseNull is missing (Breaking Change)

[CLOSED] Other breaking changes not mentioned in the Breaking changes list

[CLOSED] Breaking change: invalid/valid events are gone in Ext.Net 2

[CLOSED] Breaking change: the Column Fixed has been replaced by the Resizable property (it's in ColumnBase)

[CLOSED] Breaking Change in latest SVN

Posting Permissions

Sitemap

Downloads

Resources

Thread: [CLOSED] Possible breaking change in 3.x to 4.x upgrade

[CLOSED] Possible breaking change in 3.x to 4.x upgrade

Similar Threads

Posting Permissions

Sitemap

Downloads

Resources

Stay connected with us