Introducing FilteringList and FilteringGrid!

As you may or may not know, dgrid is a powerful tool for creating robust and optionally dojo/store-driven grids. If you haven"t been introduced to the dojo toolkit or dgrid, I advise you hop over to their sites and check them out. They may change your JavaScript programming life forever.

While dgrid does many things, as it is still young, it doesn"t have ever feature under the sun (and probably never will). The great thing about this is that it was written ontop of the very powerful dojo/declare functionality, making extending it a breeze. Since dgrid is compatible with stores, it is possible to filter the grid already by setting the store"s query, but I thought it would be useful to have this functionality packed together. Enter FilteringList and FilteringGrid.

FilteringList is an extension of OnDemandList. It takes any dojo store that implements a SimpleQueryEngine and spits out a list that is filterable. Let"s take a look at how we would implement this, and then we"ll go over the options you can use to change how it works.

Filter on fullName and company

Filter on fullName and company

As you can see, implementing a FilteringList is super easy. The list should automatically startup, but calling startup is never a bad idea. Let"s take a look at the options you can pass FilteringList and how they will affect the list.

• queryProperties - This is a list of the store properties that the filtering will iterate over. If there are no queryProperties provided, the list will default to searching over the idProperty of the store.
• store - This is the store that the list will render from.
• columns - This is a dgrid column structure.
• renderRow - Because this is a list and we"re using a store (not an array), we need to tell the list how to render from the store. If we were using just a plain array in a renderArray method, this would not be required.
• hasSearchBar - Set this to false if you don"t want the search bar to appear. If this is false, you will need to call the filter method manually. This defaults to true.
• minLength - The minimum length of the search criteria before the filtering kicks in. If the search value is less than this, the list will reset. This defaults to 2.
• filterTimeout - Timeout, in milliseconds, between search criteria changes before any filtering occurs. This defaults to 250.
• caseSensitive - Whether the search should be case sensitive.

The available methods on the list are listed below.

• toggleSearchBar - Toggles the presence of the search bar.
• filter - Filter the store of the list. Accepts a string. Does not have to be an exact match.
• set - Set various properties of the list. Accepts a property name and a value. Is used, for example, by toggleSearchBar in the form of this.set("hasSearchBar", !this.hasSearchBar)

Let"s take a look at various list implementations.

No Search Bar

No search bar

 

After manually filtering:

Case Sensitive

Case Sensitive Search

Failed Search:

Toggle Search Bar

Toggle Search Bar

Before toggle:

After toggle:

FilteringGrid

FilteringGrid is a subclass of FilteringList. It has the exact same properties and methods. The exception here is that it can display multiple columns of data, so it doesn't need a renderRow method and accepts a dgrid/Grid columns structure.

Let"s take a look at how the previous examples look in a FilteringGrid. Since the implementation is pretty much the exact same, I will not include any code examples, though they can be found in the tests included in the github repository.

Filter on fullName and company

No Search Bar

After manually filtering:

Case Sensitive

Failed Search:

Toggle Search Bar

Before toggle:

After toggle:

Truly Private Variables in JavaScript

So, I'm creating a module system for a project I'm working on, and I wanted to share a design pattern that I am using, that allows for private variables to be attached to an object. So private, in fact, that they don't even show up when you console.log the saved variable.

To see how this works, let's dive into the code for the basic module.



Simple enough. Now let's take a look at the modules class, and its register function. As a side note, Sandbox is a class that is passed to every module, which allows it to perform various functions, e.g. pub/sub.



So, now let's create an initialize a module.

As you can see, the sandbox, instance, factory, and initialized properties that were added to the module object in the "register" function are hidden from the console.log view. I can then, inside the modules class, call the modules[module.uuid].factory or sandbox or whatever, and it will be available from within the class. If you want to have access to these properties, you would simply return the module object in place of the prototype, or perhaps in place of the instance. You could also add a getter to the class to return a module by its uuid, and you would have access to those private variables.

For more information on closures (the reason this works), you can visit a really concise explanation by Douglas Crockford here.

Unique value in an array?

So, someone recently told me about an interview question they heard about for some job at Amazon. I thought the question and answer were neat, so I figured I'd share it.

The question goes: "If you were given an array filled with a bunch of numbers, where every number was duplicated exactly one time except for one number, which is only in the array once, what is the most efficient way to find the unique value?"

The answer is to iterate through the array one time, performing XOR on each of the numbers. At the end, the value you have will be the unique value.

Want to see it for yourself?

Here's a JavaScript snippet I wrote to prove it on a smaller scale. This will work on arrays of any size, however.



Speaking of XOR and interview questions, I was a part of creating the team test we give people who want to join our team, and one of the questions was to have the person write a piece of code that would swap variable values without using a 3rd variable as a "value bucket". I decided to try to do this in one line using XOR, and I pulled it off.

The JS for it is:

It's been a while!

It truly has been a while since I have posted anything here. To be quite honest, I have immersed myself in so much JavaScript best practices, new patterns, performance optimization, etc, that I have highly neglected this blog!

Since my last few posts, I have increased in my JS knowledge IMMENSELY, and that is no joke. I am w3schools certified (link to cert) *with excellence*. I got 69 of the 70 questions right! Woo hoo!

I have studied very carefully presentations, books, papers, etc from various JS gurus, Nicholas Zakas, Douglas Crockford, John Resig, etc. I actually printed out the current ECMAScript specification and read it on a flight to Las Vegas for a team meeting.

I am not joking when I say this, JavaScript is one of my biggest passions. If I could do nothing but analyze problems and engineer solutions in JavaScript all day long, I would do it!

Unfortunately, there isn't really that great of a job market that I can find. I don't have any degrees as of yet, and the area I live in really kind of prevents me from finding any solid JS jobs, and it'd be REALLY hard for me to relocate.

Members on my team at work think I'm really good at JS, and I think I'm pretty good, too. I'd like to be able to focus solely on that, as it is easily my biggest strength, but it's really hard to do that right now.

I'll keep it as a hobby, and maybe one day, I'll find a JS engineering job to call my home.

In other news, I am going to check out Dojo. I've been using jQuery for a very long time now, and I'm interested to dive into another JS library. I like what Dojo brings to the table. I haven't had a chance to dive into the source just yet, but at face value, it promises to offer some really neat functionality.

I am in the process of checking out the repository for the source now (it's huge). I like to dive into source code when I'm picking something new up.

I also purchased a book called Mastering Dojo: JavaScript and Ajax Tools for Great Web Experiences to read over the next few days.

I'm excited to really dig in and learn some new stuff!

My new favorite JavaScript pattern...

So, I've been doing a lot of reading, and I think I've finally come to the conclusion as to what my favorite JavaScript construction pattern is.

And the winner is...

I like this pattern more than this pattern:

The reason is because I feel like the first one is a little more easy to read.

It just seems a little more intuitive to me.

The conventions I use may be a little weird to you, but I'll walk you through why I have seemingly random capitalization.

Most functions and variable names I do in camelCase:

I have all objects start with a capital letter.

I know, I know -- "technically everything's an object".

To refine my previous statement, anything that's an object literal or an object created by a constructor.

Anything else, I do regular camelCase.

I find it allows me to recognize quickly where my objects are.

I'd be interested in hearing about your favorite JS patterns.

New conventions at work...

It doesn't take the smartest man in the world to know that without a good set of standards and best practices, a team of developers can have a real mess on their hands when it comes to project development and maintenance.

Last weekend, I got the privilege of being the coauthor of my team's set of best practices and coding conventions.

I am a relatively decent JavaScript developer, so I got to write the JavaScript portion of the document. I also contributed to the ASP and HTML/XML portions of the document as well.

I am pretty excited about the upcoming release of our document, as it will really help push our team to the next level, and give us scalable, maintainable code.

We've agreed to convert any page that needs edits over to the new set of standards before rerolling it to production.

This will give us some development time increases, but in the long run, the benefit is just priceless!

Optimizing your jQuery code - fragment caching rules

jQuery 1.4 really introduced a lot of cool shit. One thing in particular is the internal caching of elements. When used properly, this can drastically increase your application's performance!

A good example is one I'm currently doing. Currently, I'm working on an admin page that allows a manager to go in and add/edit/remove options, details, and other data that are used by another application front-end for our tech support partners.

I'm doing the modification via AJAX, so when they click on an option, it will grab all the details for that option, and display them, so they can be edited. I'm caching everything grabbed and holding it locally, so I only have to do one AJAX call per option.

When they click the edit button, I'm having the innerHTML of the cells of that row turn into input fields for them to type the new, edited data, and then save when they hit update, reverting back to a regular text-filled cell.

As you can tell, I will be inserting a lot of inputs.

jQuery 1.4 introduced a new way to add elements to your page.

The old way (1.3.2) was something like

or

Something like that.

Now with jQuery 1.4, you can do

This is similar to the second example, the object passed as the second parameter is an attribute object.

What makes 1.4 really awesome, though is that if you use the method of $("<input>") either with an attribute object or going $("<input>").attr(), it will cache the fragments it creates when making these.

So, when you're adding multiple elements, you're basically getting a clone of the cached fragment, and not having to recreate an entirely new element.

The speed and performance boost from this is crazy, and I'd definitely recommend messing around with it.