Five Tips to Improve Your Ext JS Application

Three Pillar Global sponsored their first Ext JS meetup earlier this week, and they were kind enough to invite me to give one of the presentations. Thanks to Patrick Sheridan (@sheridap) of Three Pillar for pulling it together, and providing the delicious pizza! My presentation was inserted between Shea Frederick and Jay Garcia‘s. Pretty good company, I’d say.

Pat started off discussing “Design for Use“. Then Shea told us all about “Practical Ext JS Debugging“.

My talk is titled “Five Tips to Improve Your Ext JS Application”. I briefly touch on five distinct strategies to use to make your code more maintainable and reusable. Below the slides and video is a short discussion of each topic:

Five Tips To Improve Your Ext Js Application
View more documents from Jonathan Julian.

Jonathan Julian at the Northern Virginia Ext JS meetup at Three Pillar Global on 1/19/10 from Jay Garcia on Vimeo.

Define your own components

Explicitly define your own “classes” as you build your UI. This will allow your code to be more reusable, testable, and maintainable. It’s really easy to do, and along with namespacing your files and only defining one component per file, this approach will lead to amazingly clear directory structure.

Use an event manager

Sometimes also known as an “event broker”, this is a simple object used to centralize all events. The example in the presentation is the “simplest event manager you can build with Ext JS”. I like to use at least one in every project to simplify the coding when someone inevitably asks, “can you make it do X every time the user does Y?”

Here I am describing the MyApp.eventManager

Fire an event on the MyApp.eventManager

Override the framework properly

Anytime you need to “hack” the framework, do your work in a special file (or dir): call it “overrides”. Then when you test your upgrade to the next version of Ext JS, all the integration points to inspect are in one place. I also included my idea of a standard directory layout. I think it works well with the idea of “Namespace Segmentation” as discussed in Chapter 16 of Ext JS in Action.

Remember, it’s still a web app

Write good JavaScript code. Use JSLint. Read The Good Parts and Even Faster Websites.

Prefer an Ext JS SPA to a classic “web app”

This is a tricky one. If you have the choice, build your application in two tiers – Ext JS, and web service. They don’t even have to share the same endpoint! A cleaner design emerges when you separate the concept of the Ui and the data. If you work on a project that already muddles the two with server-side script tags and generation of Ext JS configs with “helpers”, then make it a goal to write all new code in the two-tier style. Put your Ext JS code in .js files. And only communicate with the server via JSONStores and Ajax requests.

jjulian/winner_picker

The winner_picker UI.

The Winner Picker App

Shea brought a few copies of Learning Ext JS, and Jay brought a few vouchers for an early access copy of Ext JS in Action. We needed a way to give them away – so, I dreamed up a simple app to randomly choose an attendee. To make it fun, I wanted to have a slick animation to randomly highlight attendees names for a few seconds before the choice is shown.

In less than an hour or so, here’s the Ext JS app I made: it’s a grid with an Array Store (attendees were entered manually), and one button that kicks off the process. And the silly animation: every 10ms, a grid row is selected at random and highlighted. The delay is slowly ramped down for effect. After a few seconds, the last random choice is made, and a message box is shown with the winner’s name. The code is on github, and I encourage you to fork the project and improve it, for no other reason than practice (basic knowledge of git is easy to get). The Five Tips can be applied to this tiny project just as well as they can to your large enterprise project!

Conclusion

I think it was a successful event, and I hope to be involved in the future. There were a handful of intense discussions afterwards – it’s good to be a part of a passionate community! If you are in the Baltimore area, come on out to our JavaScript meetup and hang out with us on the first Wednesday of every month. We meet at the Beehive in Canton. If you are in NOVA and want to help build the Ext JS meetup scene there, get in contact with Pat (@sheridap) or Jay (@tdgi).

I’d love to hear what you think about the Five Tips. Feel free to comment here, or on the slideshare page!

  • http://www.extjswithrails.com Steffen Hiller

    Thanks for the blog post and slides. I like the shortness of the slides. But it's a shame that I couldn't be at the meeting, I guess that's why I miss some background info.

    Could you share the advantages you see with the central event manager you mention in your slides? (Maybe with an example :-P)

    Thanks,
    Steffen

  • http://jonathanjulian.com jjulian

    Hey Steffen – another great benefit of an event manager is to enable decoupling of components. This allows you to develop and debug your components in isolation from each other.

    It's the classic concept of “responsibility”. One component should not have to worry about the implementation of another, or many other components. Did the user click on one of your nodes? Update yourself, then fire an event to the world saying “hey, this specific node was clicked”. All the other components that care will hear it, and do their own thing.

    The overhead and documentation is minimal, and I'd argue that it makes it even easier to search your code. For example, name an event “genretreenodeselected” and it's simple to search your codebase for all the places where that event is used.

    This is in addition to being able to separate your UI definition from the run-time behavior. I've worked on some complex single-page-apps, and being able to clean up and clarify the code is a big deal.

  • rwaters

    Jonathan, you hit the nail on the head with loosely coupled components. If you design components that call specific methods that exist in an instance of another component directly you're stuck only being able to use it for that purpose unless you remove that bit of code when trying to reuse them.

    Now, there are certainly cases where a component I'm creating is so specific that it will only ever be used for the one purpose/place it's being used… but I always try to imagine how I can make them more reusable and generic enough that I could put them elsewhere.

  • http://jonathanjulian.com jjulian

    Yeah Rich, I wish I would have added “de-coupling” to my slide deck. After I made that point on Tuesday, Jay Garcia pointed out that a de-coupled component is much easier to load up in a blank viewport for testing when something is not working. I think that nails it!

  • http://www.extjswithrails.com Steffen Hiller

    Thanks for your comments!

    I wish we could discuss this while looking at the code of one or event better various Ext JS applications.

    I can't help having the feeling that de-coupling of components is overrated.
    Maybe each of us has different scenarios in mind.

    Regarding “Now, there are certainly cases where a component I'm creating is so specific that it will only ever be used for the one purpose/place it's being used… but I always try to imagine how I can make them more reusable and generic enough that I could put them elsewhere.”
    Maybe my experience just showed me, that I will reuse components less then I would think, so for the sake of simplicity, I call the other component directly and save myself a d-tour.
    I do reuse components though, but then in the pattern of inheriting from an Ext JS component and when instantiating for a specific view, I'll add my custom listeners for the components that “couple” with the components of the current view.

    (Automatic) testability is an argument that would motivate me to look more into de-coupling though.

    It's kind of hard to talk about it without specific examples.
    Wish I could go to y'alls user group meetings. Wondering how it'd be possible to better communicate over the internet on this topic.
    Maybe the more complex official Ext JS examples are a good place to discuss different approaches.
    Y'all don't know any open source Ext JS application that also could serve as a good example (of any approach)?

  • http://www.extjswithrails.com Steffen Hiller

    Btw, I recently started working on an Ext JS (with Rails) app for my own. This app will serve as a playground while being a serious productivity app that I already use. I plan to use it to try out different approaches and blog about it. You can already check out a working version at http://spreadnotes.me. Ignore the missing styles and images on the front page. </self-promotion> :-)

  • http://jonathanjulian.com jjulian

    Have a look at the feed-viewer in the ext 3.1.0 examples. When a selection changes, the FeedPanel fires event 'feedselect'. The FeedViewer listens for 'feedselect', and loads the selected feed.

    While this example does not explicitly use a separate event manager (FeedPanel fires the event on itself), it is a good example of de-coupling components. Note that the FeedPanel does not explicitly look up the FeedViewer and load the feed.

  • Pingback: uberVU - social comments

  • christocracy

    I couldn't agree more with your suggestions. I use the same directory-structure you prescribe.

    The goal of one's “overrides.js” file should always be to keep it empty.

  • VinylFox

    Excellent advice without a doubt. As your applications get larger and larger, and requirements change, the points given by Jonathan will start to make complete sense.

    Glad you were able to present at this event with Jay and I.

  • http://jonathanjulian.com jjulian

    I've embedded the video from the talk above – thanks to Jay for encoding and uploading to vimeo!

  • http://jonathanjulian.com jjulian

    I've embedded the video from the talk above – thanks to Jay for encoding and uploading to vimeo!

  • http://www.medyumburak.com Medyumlar

    I've embedded the video from the talk above – thanks to Jay for encoding and uploading to vimeo!

  • Johan van de Merwe

    I have watched the video and it helped me a lot in integrating the Event manager in my applications. For I had missed this part completely. Thank you. Good advice and I have great results.