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)

ExtJS 6 DataBinding vs. Premium Licensing

I recently ran into some frustration as I was doing some refactoring and my databinding stopped working for some view. Turned out I misspelled “viewmodel” where it should’ve been “viewModel” and it didn’t get declared for one of the views. As a result, a simple HTML bind like this stopped working:

xtype: 'component',
bind:'<div class="stacked-label-group">' +
        '<div class="label-title">{i18n:translate("appointment_info.appt_info.promise_time")}</div>' +
        '<div class="label-value">{promisedDateOrWaiter}</div>' +
     '</div>'

Turned out that I didn’t have a “promisedDateOrWaiter” to bind to (since I didn’t actually have a view model), which caused even the label data binding to fail to render (even though that one did exist at a different higher level). So the danger with these view models is that even if one of many fails in the binding, the whole binding fails (at least in case of html type of bindings).

Unfortunately this isn’t easy to troubleshoot as there are no error messages in the console or exceptions to pause on.

However, Sencha does offer an Inspection tool: https://www.sencha.com/products/inspector/

I evaluated it and one of the features it offers is being able to catch faulty bindings like this one. The ironic part is that you need to purchase a “premium” license to get the tool, which is almost double the cost of the standard license just to get the framework. I really hope Sencha will write some tutorials on how to debug these data bindings effectively without the custom tool.

VN:F [1.9.22_1171]
Rating: 4.9/10 (23 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)