Evolution of a Feature: Helpers

Originally, Jax borrowed its concept of “helpers” from Rails in that they were meant to be supporting libraries of functions used almost exclusively within an application’s views.

As Jax has evolved, it’s become apparent that views don’t change all that often. In fact, they’re so static that most people will probably rarely, if ever, edit the views at all.

So why do we need helpers for the views? The short answer: we don’t.

I was planning to remove the helpers outright, but decided to play with the idea of using them for organizational purposes beyond just views. The result is pretty amazing, and now I’m so confident in their ability to keep an application manageable that I’ve already added how to use them to the Getting Started guide.

Helpers are easy to define and easier to use. First, in the app/helpers directory, create the helper (note that Jax actually generates this step for you, so all you have to do is add the test_method to an existing helper):

var SpiffyHelper = Jax.Helper.create({
  sayHello: function() { alert("Hi there!"); }
});

Once defined, using the helper in any Jax class is a one-liner:

var klass = Jax.Class.create({
  // ...
  helpers: function() { return [ SpiffyHelper ];
});

That’s it! A minor feature to be sure, but one that will have a significant impact on your application as you identify areas where code reuse would be a major plus.

The example I used in the Guides is where you want to handle user input similarly across all controllers; now, instead of copying and pasting (which is a Bad ThingTM), you can just stick the user input code into a helper and apply it to whichever controllers you want!

One additional note is that, if you add methods to the ApplicationHelper, Jax will automatically include this into any Jax class. So you don’t need to explicitly specify a helpers function on your classes in order to include methods that are common to all classes; just put it in the ApplicationHelper and you’re done.

Comments are closed.