JavaScript, Go With the Flow!

As a technologist gluten, I probably spend too much time on different technologies and not enough time on any one particular one.  It does find me often frustrated with seemingly basic things that should take little time to solve.  Recently, a friend sent me a quote which sadly applies to me too much.

To be successful as a programmer, you, first and foremost, have to be a nerd.  You were probably born that way, but in any case, you already know if you are.  You are the kind of person who can stare at a screen for 14 hours puzzling over why the damn call to xref = malloc(len); is not accompanied by the appropriate call to free(xref); about 1 out of 100,000 times, and that’s why the frigin fuel injector hangs up on the new Mazda – and feel refreshed, energized, and dying for more.  Not everyone can – or wants – to do this.

Anyhow, where was I.  Oh yeah, JavaScript and going with the flow.  I’m pushing to get a SenchaTouch app done right now so I can make the January 21st deadline for putting a Blackberry 10 app together and getting it into there store.  I’m close! (I think).  I find myself staring at the following code that I’ve written.  Basically, I’m taking data that I got from a web service and updating a screen full of fields.  First, I DeRef all the data into local variables, then I set that data in the panel (form).

var customerFullName = obj.Data.CustomerFullName;
var cumulativeStarBalance = obj.Data.CumulativeStarBalance;
var cardDollarBalance = obj.Data.CardDollarBalance;
var numStarsTillNextDrink = obj.Data.NumStarsTillNextDrink;
var numUnredeemedRewards = obj.Data.NumUnredeemedRewards;

var goldCardPanel = Ext.getCmp("GoldCardPanelId"); 
    customerFullName: customerFullName,
    cumulativeStarBalance: cumulativeStarBalance,
    cardDollarBalance: cardDollarBalance,
    numStarsTillNextDrink: numStarsTillNextDrink,
    numUnredeemedRewards: numUnredeemedRewards

I start to notice that I’m repeating myself kind of so I’m thinking maybe I only need to do this once and I can half the size of the code.  Then I say to myself, Self: does it really matter that our template uses lower case and not upper case variables? (obvious answer is no, I often talk to myself in rhetorical questions).

So, the rewrite is this:


Just Sayin…

About Peter Kellner

Peter is a software professional specializing in mobile and web technologies. He has also been a Microsoft MVP for the past 7 years. To read more about Peter Kellner and his experience click here. For information about how Peter Kellner might be able to help you with your project click here.

Follow me:


  1. Peter Kellner says:

    I’ve always found that conventions that are different then everyone else uses always get me in trouble and ending up break down. I know JavaScript is hugely flexible. Any way to have JavaScript do some wizadry on my behalf that I could reuse?

    BTW, just read your blog and watched your video. Very nice! I wish I had artistic and music skills. You are blessed! I also noticed you run the local meetup. Me too! If you are in town on Feb 6th, we are doing a “meet the SA team”. It should be very fun.

  2. I only do a little bit of C#, but my point is to simply be consistent. And I can certainly understand the desire to limit the data transformations between client and server.

    In my opinion, if you’re going to use upper-casing to name object properties that’s fine… just ALWAYS do it. People will certainly disagree with me – it’s a hot-button topic. I see nothing wrong with it.

  3. Peter Kellner says:

    Thanks Arthur,
    I am in an MVC controller so I could do that. I’ll take a look (and also keep in mind your comments about consistency). The issue I keep running into is that the common convention in JavaScript for casing seems to run in conflict with c#. That is, I download public properties from my ASP.NET MVC controller which come down with Uppercase start and JavaScript variables in objects seem to want to be lowercase start. Is that true? (asking a passionate JavaScript guy). As a passionate c# guy I don’t want to change my server side to send down lower case start. Any way to have the JavaScript handle that in a consistent way or am I having to make the choice between long adapter type and consistency, or doing what I did here which I agree is problematic for lots of reasons in the long term.

    Thanks again for your comments. It really helps me understand better the echosystem I work in.

  4. The performance of Ext.getCmp() may or may not be better than a ComponentQuery… it’s completely dependent upon the query and how it’s used.

    In your example, you might use an “itemId” rather than an “id” config on the GoldCardPanel component. Then you can grab this component via ComponentQuery in any number of ways… but as I mentioned, this might make the most sense inside an MVC controller.

    The easiest ComponentQuery for your GoldCardPanel would simply be “#GoldCardPanelId” (assuming you moved the “id” to an “itemId” with the same name).

    However, there’s lots of possible ways to use ComponentQuery – inside or outside the Controller. The Sencha Touch API docs have a ton of information on that so I’d start there.

  5. Peter Kellner says:

    Hi Arthur,
    Thanks for the comments! I’m hoping to get comfortable enough writing JavaScript that “going with flow” is writing excellent JavaScript. You make great points (and please keep making them).

    Can you explain in more detail both the performance difference using getCmp verses ComponentQuery? Also, what would the component query look like in my example to get the same thing (and what attribute if any would I need to add to GoldCardPanelId.

    Thanks again, -Peter

  6. I certainly like the approach of having less code (and the optimization). But two points:

    (1) Ext.getCmp() is probably not something I would normally recommend in production apps. Controllers (via ComponentQuery) are almost always a better option for organization and architecture.

    (2) You said to yourself: “Does it really matter that our template uses lower case and not upper case variables?” Perhaps it’s a trivial point, but I would certainly argue that CONSISTENCY in your naming conventions is important. If you’re the only developer then I suppose it doesn’t make much difference… but on projects where many developers are editing the same code, having a strict standard makes a huge difference in the maintainability and stability of your application.

    But then again, I’m just passionate about JavaScript!

Your Comments


Protected with IP Blacklist CloudIP Blacklist Cloud


Get every new post delivered to your Inbox

Join other followers: