All About Ext JS Layouts

It was exciting to see the many attendees at Virtual SenchaCon 2020 and the wide range of topics presented. As a long-term Ext JS developer, it was a great opportunity for me to talk about and share my experience with Ext JS Layouts. Since we fell short of time, I wanted to come back and answer the audience questions in this post. I’ll use a simple Q &A format to address your questions.

Given the overwhelming response, I’ll be conducting a follow up presentation (May 21, 2020 @10 am CST) on the same topic and answer more questions. You can register to attend here.

Many folks were interested in seeing the presentation application that I used during my talk. I’ve uploaded the Layouts tutorial here — so take a look.

Using modern toolkit with material theme in a desktop, how would you better design a form so inputs are not as wide as the screen?

I typically just use bodyPadding:8 and layout:’form’. In other words, the fields are 100% wide, but don’t actually bump up to the edge because of the body padding. I use padding or bodyPadding routinely.

I’m writing a new application and our users are internal to our company. The users will have Chrome, IE11, or Edge browsers. We would like to have the option of mobile pages at some point, but that’s a couple years away. I’m still not sure if I should choose Classic or Modern.

(See below for a similar question and discussion.)
Those are modern browsers, so modern is the obvious choice. However, the modern and classic frameworks are still not quite at parity. Overall, classic might have a few more features, although the modern grid hierarchy is better.
Classic’s advantage is that it’s been around so long that all the kinks have been worked out. It’s tried and true. Modern has some improvements, and it renders much better, but since it’s less mature, you may find* a missing feature now and then.
I’m on a large multi-application project for a major high-tech corporation, and we’re still writing new apps in classic, as well as modern.

* If it’s possible to “find” a missing feature. ;-)

My first project in Ext JS was in version 3.4 and now we are at version 7.2. How come I still find myself “going Classic” all the time, even with the audience having modern browsers? Why is Modern always leaving a bad taste in my mouth by missing some key items (that I always find too late in a project)? Proof Points: lacking localization, international support (decimal, thousand separator, date format etc.) and ARIA.

I hear ya! The same thing happens to me. I’ll use modern, then months later hit a few gotchas which make me regret it. Modern has some nice things, like better grid features, but classic is the “safe” choice.
Sencha read your question, and hears similar things from other people too — hopefully they take those comments into account as they plan what goes into their releases.

Do different container types have different default layouts if you omit it?

Yes, which is good and bad. It’s good, because the defaults are logical, but it’s bad because it may not be obvious to whomever is maintaining the code.
I generally explicitly specify the layout even when I’m using the default, just to make the code more readable. But I don’t do that for containers where you aren’t thinking in terms of a layout, such as with toolbars or button menus (menus extend panel!).

In complex layout options sometimes needed a mix of few layouts, however some layouts are not working together (the main issue I faced is related to border layout). Do you faced this kind of issue and what do you think, all layouts should work together or not?

I think layouts do work together! So maybe there’s something else going on in your code, or there’s a bug. Email me at [email protected] and we can put together a fiddle to explore your layout combination. :-)

How do you handle “natural size” in the wild? With 27″ monitors a typical form looks awful. To handle that I often set maxWidth. Is this bad practice?

Handling wildly varying run-time environments is a design challenge. Addressing it would make a good presentation all by itself. But here’s a start…
First of all, you have to decide if the various run-time environments are just slightly different versions of the same thing, or if the whole UI is different. For example, a desktop and a phone version may have similar features, but would have very different flow and layout. On the phone you’d do more drill-down, whereas on the desktop you have room to show multiple things at once. But the tablet version may be similar to the desktop version. In your case, you may lay things out differently if the user is running VGA versus 1080p! (Note that the 27″ monitor may be big, but it still may be 1080p).

ExtJS addresses that in a few ways.

If the views are very different you can either use app profiles or build profiles to specify completely different sets of views based on the run-time form factor, each with their own layouts and content. See the docs on Ext.app.Profile and XX to read more about these. I find build profiles easier to work with, but it may be a matter of taste.
If the views are similar, and just need slight adjustments, you can use responsiveConfig. It’s pretty awesome, and can be used to adjust just about any view property that has a setter based on any rule you’d like. There are some built-in ways of detecting whether the user is on a desktop, tablet or phone — some are built into responsiveConfig , and are also available via Ext.platformTags.

I am just starting with Sencha Architect and am looking for a recommended methodology to migrate my iOS application to Sencha Architect to support both iOS and Android?

There’s no specific method for migrating an iOS to ExtJS, other than simply re-implementing your old app’s views and flow using ExtJS.
ExtJS apps, like any HTML/JavaScript app, can be wrapped up for deployment to the app stores.

Architect has a Build Native feature documented in the Building Native Android Apps getting started guide and in the Save, Preview, and Build guide.
There’s also information in the Integrating With Cordova or PhoneGap guide, which covers the procedure whether or not you’re using Architect.
If your app uses native features, unavailable to the browser, then Cordova is the way to go, but if your app is a standard browser-based app, I’d explore just “deploying” it as a URL. The user is still able to save-to-desktop (i.e., their phone desktop), which means it behaves like an installed app. Again, I realize if you need native features that’s not an option.