Layout Run Error: Case of Hidden

It seems that I have started cataloging my experiences with the rather common Layout Run Error in ExtJS portals, as it’s one of the most frustrating errors to fix. Previous editions include:

This time I came across another rather simple scenario where I was troubleshooting something unrelated and in process was setting “hidden: false” on various components, in hopes of divide-and-conquering my way out of the issue.

Sure enough, got a “Layout Run Error” when I set one of my components as hidden. There was nothing particularly special about it – a Container extension sitting inside of another Container with “auto” layout. At that point I commented out my Container instead of setting it hidden: no more layout run error!

I decided not to spend time figuring out why this particular container didn’t like being hidden from the very beginning, especially considering this is in context of rather stale 4.2.1 ExtJS codebase. Nonetheless, the lesson is: even a simple act of having component declared as “hidden: true” initially can be enough to cause Layout Run Error.

VN:F [1.9.22_1171]
Rating: 5.8/10 (21 votes cast)

Layout Run Error: Case of Toolbar

Last year I wrote about the rather grim approach to troubleshooting ExtJS 4 (or 6 Classic) “Layout Run Error” issues:

Debugging ExtJS “Layout Run Error”

Now I came across a scenario now with a rather simple and unexpected fix. Consider this scenario where a panel specifies defaults for the “collapsible” behaviors of its child panels, but also has a toolbar as a child:

{
    title: 'Floating Footer',
    autoScroll: true,
    defaults: {
        xtype: 'panel',
        collapsible: true,
        collapsed: true,
        titleCollapse: true,
        margin: '0 30 0 30'
    },
    items: [{
        title: 'Panel 1',
        margin: '30 30 0 30',
        html: 'Panel content!'
    },{
        title: 'Panel 2',
        html: new Array(1000).join('Lorem ipsum '),
        collapsed: false
    },{
        title: 'Panel 3',
        html: 'Panel content!'
    },{
        xtype: 'toolbar',
        margin: '30 30 30 30',
        items: [{text: 'Back'}, '->', {text: 'Next'}]
    }]
}

A seemingly harmless configuration, this would throw “Layout Run Error” all day long with ExtJS 4.2. Why? Because apparently the “collapsible” configurations in the defaults somehow affect the toolbar (who while not a panel, but is a container). Easy fix – negate those configurations on the toolbar:

{
    xtype: 'toolbar',
    margin: '30 30 30 30',
    collapsible: false,
    collapsed: false,
    titleCollapse: false,
    items: [{text: 'Back'}, '->', {text: 'Next'}]
}
VN:F [1.9.22_1171]
Rating: 4.7/10 (21 votes cast)

ExtJS 6: Responsive HBox vs. VBox

A basic ExtJS6 Classic Toolkit responsive technique for going from vertical to horizontal based on tall/wide screen, is by using responsiveConfig on a Viewport running Border layout, and change desired child’s regions from i.e. South to West. However, what if you want to do the same, but using an HBox vs. VBox layout, to get that additional flex functionality? Turns out it’s not as straightforward, however still pretty simple. You just need to use Box layout (ancestor of HBox and VBox) with “vertical” boolean config changing inside the responsiveConfig of the viewport. Here is the sample source code from Sencha Fiddle; click the link below to experiment with it in different window sizes:

https://fiddle.sencha.com/fiddle/sls/preview



VN:F [1.9.22_1171]
Rating: 6.9/10 (7 votes cast)

Layout Renders Partially – How To Fix

Last year I wrote in-depth about ExtJS “heavy” JavaScript layout system in Sencha’s blog: http://www.sencha.com/blog/exploring-the-layout-system-in-ext-js-5-and-sencha-touch

Recently I discovered a rather interesting “issue” that all big ExtJS apps will hit eventually: the app will start “misbehaving” in a sense that very complex sections will sometimes render only partially and the UI will become unresponsive. This one will be extremely painful to figure out, as this is actually a result of a “silent failure” by the ExtJS layout system, due to a pre-emptive assumption of “if you’re running too much layout, you probably did something wrong” by the framework. Read on for an easy fix…

Continue reading Layout Renders Partially – How To Fix

VN:F [1.9.22_1171]
Rating: 7.8/10 (9 votes cast)

ExtJS 6 vs. Responsive

A few weeks ago I was at SenchaCon 2015 and majority of the sessions I attended revolved around ExtJS6 and Sencha’s responsive strategy. In summary: an effort has been made to converge ExtJS5 and Sencha Touch 2, but ultimately you will still be building a separate ExtJS and a separate Touch app. You do not end up with truly “one framework”, which is what I hoped for. Read on for details…

Continue reading ExtJS 6 vs. Responsive

VN:F [1.9.22_1171]
Rating: 8.1/10 (13 votes cast)