The Hottest ExtJS 3.0 Feature You’ve Never Heard About
Alright, now that I have your attention with that snappy title, I can talk about a little unknown feature of ExtJS 3.0 that will definitely make your life easier and shorten your code by a few lines - "ref" (everything should come with a "web 2.0" logo)
This new config that was introduced in ExtJS 3.0 provides us with a way to create a reference to a component right in the config. It's so simple its complicated, so I think it's quickly become time for an example...
Let's say your extending panel to create a custom component with two buttons in a bottom toolbar, it might look something like this:
It's lines 18, 19 & 20 that make me uneasy. When im inside extending a component, I don't feel like it should be necessary for me to have to locate a component that is nested within the component im creating and manually assign it to the scope - right?
When we put the new ref config into use, our code will look something like this:
The only way to describe this is "clean". Now lines 18 & 19 are working directly from my local scoped variables, referencing components contained within my component. No messing around with finding the component and manually assigning it to a variable in the scope. Not to mention, with this very short example we were able to save six lines of code, which is a great savings when your only talking about twenty-seven lines of code total - that's a 20% savings!
The Nitty Gritty
The ref config works much like changing folders on a linux command line, two dots and a slash travel up one level of folder, or in the case of ref, a level of nested component. It takes care of adding the scoped variables for you using the name you provide in the ref config.
Summary
This is one of those things you find often in ExtJS that really set it apart from other RIA libraries - one of the many reasons I use and recommend the ExtJS library for projects over and over again. Simplicity in a highly configurable UI component is not an easy thing to balance, but ExtJS has managed to do it again and again.
NOTE: Something as trivial as adding a toolbar and buttons to a panel is not a reason in itself to create an extended component, this is simply for the purpose of having a minimalistic example - no matter how pointless it might be.
Great post dude.
Thanks Jay.
One other thing I should note is that there is no performance hit by using ref as you might expect from shortcuts like this – both these code examples run at exactly the same speed.
Wow — and this can be done with pretty much _any_ component?
Yep – anything that extends from Ext.Component – the ref’s are setup at the end of rendering the component. Check out the initRef handler in the Component.js source file.
this is great stuff, awsome, asking permision to translate to spanish and posted on a spanish website about extjs (quizzpot.com).
woah.. just came across this. i’d totally forgotten about the ref config! great post =)
p.s. the initRef() method only bothers about slashes, but the dots definitely help to improve readability.
Great post man. Ext is just great
You might extend a component if you used the same Panel+Toolbar in several different places, and wanted each instance to be identical, or at least start with identical basic config options.
Your absolutely correct Jesse, assuming you would be using the same panel+toolbar setup over and over again, then creating a pre-configured panel like this would be very helpful to centralize and reduce code.
Any plans to update your book for Ext 3?
I am trying to cleanup my code using this ‘ref’ new trick but I am getting undefined references. I have a viewport containing various panels. Each panel has a ref config option as such ref:’../name_of_panel’
If I put this.name_of_panel in the afterRender of the viewport I get back undefined… am I missing something here (I am sure I am doing something ridiculously stupid)?
Cheers,
Dado
Ext ties references using the new ref config. but the references are never deallocated. It would be better if Ext could store the ref’s and on onDestroy method, deallocate.
I’m just wondering if all this references could end up on a big memory leak…
How exactly did you come to this conclusion?
The fact that “refs” are set after rendering the component makes it of limited use. It would be a great tool if “refs” were set when a component is first instantiated, before rendering and everything else. I ended not using them to not constantly worrying about whether a component was rendered or not before using them.
I agree, that factor definitely limits their use. I still use them quite often though, mostly for user interactions that I know wont happen till the UI has been rendered.