Extjs Widget Factory

What every good extjs application needs is a Widget Factory.

Over time our project team gravitated naturally to this pattern, and suspect it is a common pattern in the community.

Let me break it down..

When developing an extjs GUI you might have a label or other component configured in your panel like this:


You will find your code getting very bloated and messy if you only do things this way, and it is also difficult to perform global changes at once, like for example changing the margins for all your textfields at once; You have to go to every individual hard-coded item and change them in the config code. It’s a pain in the butt.

Configuring all your GUI code this way creates all sorts of frightening looking highly indented extjs hierarchies, so the natural way of thinking is to refactor out these configurations into some kind of a factory.

Lets start thinking about factories..

You might define a class called WidgetFactory and make it a singleton :


And then you could add a createLabel method to the factory. Calling it from the previous example, the code would look cleaner :


That implementation of the method is obviously a bad idea because a specific order is required for the method parameters. It is much cleaner to bundle this up into an anoymous config object like so :


The implementation of this createLabel method in our factory might look like this.


But it’s still not good enough. What happens when config arguments are missing? We will get all sorts of ‘undefined’ problems. The method wants to do something with those three values.

For these values, it is therefore better to define a default value, and then overwrite it if it appears in the config object.

The improved method :


Refactoring this then gives us even cleaner code :


Our widget factory contains around seven factory methods including createTextField, createTextArea, createComboBox, and we expect to add more in the future.
The textfield factory method is used very often, so the method is huge as a number of default values need to be set.

Here is a similar createTextField example :


What is interesting to note about this method is that xtype can also be passed in as a configuration parameter. This means that the widget type can be changed from what the method is intending to return. This is useful for things like DateField which is a subtype of TextField; you are in effect creating a different xtype but using the same configuration as a textfield.

Also, some parameters can feed into the default value of other parameters, eg clazz.

Update :

SenchaMitch has an even cleaner solution. Using the Ext.apply() method, a default configuration can be defined, and then later have its values overwritten when a new config object comes in :








Posted in extjs | Tagged , | 2 Comments

2 Responses to Extjs Widget Factory

  1. You could likely optimize this a bit with using Ext.apply like I show here: https://fiddle.sencha.com/#fiddle/mob This will override any of the default configs and allow you to add new configs.

    For listeners like you have in the createTextField method, I would add it after the Ext.apply. In fact, I’d create the actual component using Ext.create or Ext.factory, then use the on method as if I pass in listeners I could break your code. Also, you should use a method on the singleton to resolve the listener to so you’re not creating an anonymous function for each textfield.

  2. Oh, also, you could do this with abstract classes instead of a factory also. But to each his own on that.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">