MooTools Behavior

Written By Aaron Newton, on Tuesday, December 20th 2011, 7:51pm

Those of you who follow my work over on Clientcide may already be familiar with it, but for the rest of you I wanted to write a blog posts here on MooTools.net about the work I’ve been doing on a library called Behavior - a throwback to the behavior.js library released way back in 2005 which one might consider to be philosophically an ancestor of sorts.

Purpose

All well-written web sites / apps that are interactive have the same basic pattern:

Web app layers

Each page of a site or app you build is esoteric. It may have any combination of interactive elements, some of which interact with each other (for example, a form validation controller might interact with an ajax controller to prevent it sending a form that isn’t valid). Typically this “glue” code exists in a DOMReady statement. It says, get this form and instantiate that class with these options. This code is brittle; if you change either the DOM or the code the state breaks easily. It’s not reusable, it only works for a specific page state. It can easily get out of hand.

Behavior attempts to abstract that DOMReady code into something you only write once and use often. It’s fast and easily customized and extended. Instead of having a DOMReady block that, say, finds all the images on a page and turns them into a gallery, and another block that searches the page for all the links on the page and turns them into tool tips, Behavior does a single search for all the elements you’ve marked. Each element is passed through the filter it names, where a filter is a function (and perhaps some configuration) that you’ve named. Each of these functions takes that element, reads properties defined on it in a prescribed manner and invokes the appropriate UI component.

Why?

The nutshell is that instead of having a DOMReady function that finds the stuff in your DOM and sets up instances of classes and whatnot, you put the configuration in the HTML itself and write the code that calls new Foo(...) only once. Example:

So instead of this:

$$('form').each(function(form){
  new FormValidator(form, someOptions);
  new Form.Request(form, someOptions);
});
new Tips($$('.tip'));
$$('.accordion').each(function(container){
  new Accordion(container.getElements('.toggler'), container.getElements('.section'), someOptions);
});
//etc

You do this:

<form data-behavior="FormValidator FormRequest" data-formvalidator-options="{someOptions}">...</form>
<a data-behavior="Tip" title="I'm a tip!">blah</a>
<div data-behavior="Accordion" data-accordion-options="{someOptions}">...</div>

Think of it as delegation (as in event delegation) for class invocation. If you use DOMReady to do your setup and you want to swap out some HTML with AJAX, you need to reapply that startup selectively to only your components that you’re updating, which is often painful. Not with Behavior, you just apply the filters to the response and call it a day.

You do a lot less DOM selection; you only ever run $$('[data-behavior]') once (though some filters may run more selectors on themselves - like Accordion finding its togglers and sections).

DOMReady setup is always closely bound to the DOM anyway, but it’s also separated from it. If you change the DOM, you might break the JS that sets it up and you always have to keep it in sync. You almost can’t do that here because the DOM and its configuration is closely bound and in the same place.

Developers who maybe aren’t interested in writing components don’t need to wade into the JS to use it. This is a big deal if you’re working with a team you must support.

Behavior is designed for apps that are constantly updating the UI with new data from the server. It’s not an MVC replacement though. It’s designed for web development that uses HTML fragments not JSON APIs (though it can play nicely with them). If you destroy a node that has a widget initialized it’s easy to make sure that widget cleans itself up. The library also allows you to create enforcement to prevent misconfiguration and an API that makes it easy to read the values of the configuration. (More on that in a bit).

There are some other nifty things you get out of it; you get essentially free specs tests and benchmarks because the code to create both of them is in the Behavior filter. Here’s an example of what it takes to write a spec for a widget and ALSO the benchmark for it’s instantiation (this uses Behavior.SpecsHelpers.js).

Behavior.addFilterTest({
  filterName: 'OverText',
  desc: 'Creates an instance of OverText',
  content:  '<input data-behavior="OverText" title="test"/>',
  returns: OverText
});

This code above can be used to validate that the HTML fragment passed in does, in fact, create an OverText instance and it can also be used with Benchmark.js to see which of your filters are the most expensive.

Delegator

Included in the library is also a file called Delegator which is essentially the same thing except for events. For example, let’s say you have a predictable UI pattern of having a link that, when clicked, it hides a parent element. Rather than writing that code each time:

document.body.addEvent("click:a.hideParent", function(e, link){
  e.preventDefault();
  link.getParent().hide();
});

You register this pattern with Delegator and now you just do:

<a data-trigger="hideParent" data-hideparent-options ="{'target': '.someSelector'}">Hide Me!</a>

It provides essentially the same value as Behavior, but at event time. The above example is pretty straight forward so, you know, why bother, right? But consider how many of these little things you write to make a web app function. If you can create them once and configure them inline, you save yourself a lot of code.

BehaviorAPI

This stand-alone library facilitates reading values from element data- properties. Examples of the HTML expressions evaluated are as follows (all of the following produce the same output):

<tag data-behavior="Filter1 Filter2" data-filter1-options="{'opt1': 'foo', 'opt2': 'bar', 'selector': '.selector'}"> //prefered
<tag data-behavior="Filter1 Filter2" data-filter1-options="'opt1': 'foo', 'opt2': 'bar', 'selector': '.selector'"> //no braces on JSON
<tag data-behavior="Filter1 Filter2" data-filter1-options="{'opt1': 'foo', 'opt2': 'bar'}" data-filter1-selector=".selector">
<tag data-behavior="Filter1 Filter2" data-filter1-opt1='foo' data-filter1-opt2='false' data-filter1-selector=".selector">

The -options value is parsed as JSON first (it’s slightly more permissive in that you don’t have to wrap it in {} just for convenience). Values defined here are read as defined allowing you to express arrays, numbers, booleans, etc. Functions / callbacks are generally not used by Behavior.

If you attempt to read a value that isn’t defined in this options object, the property name is attempted to be read from the property directly (e.g. data-behaviorname-prop). This value is always a string unless you specify a type. If a type is specified the value is run through the JSON parser and validated against that type.

Even if you don’t want to use the whole Behavior suite, this library may be of use if you like the idea of including configuration inline. There’s a lot more in BehaviorAPI so it’s worth perusing the docs for it.

Documentation

Stock Behaviors

Check out these resources of available Behavior Filters provided by the author:

Demos

Notes

Below are some notes regarding the implementation. The documentation should probably be read first as it gives usage examples.

  • Only one selector is ever run; adding 1,000 filters doesn’t affect performance.
  • Nodes can have numerous filters.
  • Nodes can have an arbitrary number of supported options for each filter (data-behaviorname-foo="bar").
  • Nodes can define options as JSON (this is actually the preferred implementation - data-behaviorname-options="<your JSON>").
  • Elements can be retired w/ custom destruction; cleaning up an element also cleans up all the children of that element that have had behaviors applied.
  • Behaviors are only ever applied once to an element; if you call myBehavior.apply(document.body) a dozen times, the elements with filters will only have those filters applied once (can be forced to override and re-apply).
  • Filters are instances of classes that are applied to any number of elements. They are named uniquely.
  • Filters can be namespaced. Declare a filter called Foo.Bar and reference its options as data-foo-bar-options="...".
  • There are “global” filters that are registered for all instances of behavior.
  • Instance filters get precedence. This allows for libraries to provide filters (like http://github.com/anutron/more-behaviors) but for a specific instance to overwrite it without affecting the global state. (This pattern is in MooTools’ Form.Validator and works pretty well).

Limitations:

  • Due to the DOM-searching for both creation and destruction, you can’t have behavior instances inside each other.

Downloading

You can find Behavior on github and also on Clientcide where you’ll also find a builder. That builder will also let you get the stock behaviors from Clientcide and the ones I’ve authored for MooTools More. If you want to get to the bootstrap builder, be sure to select “MooTools Bootstrap” in the top menu (or just clicketh hereth).

8 Responses to “MooTools Behavior”

  1. Jonathan says:

    Wouldn’t this cause HTML validation (not Mootools Validation, W3C) issues in older browsers?

    Plus, I think that the net result would be more text written, meaning more bytes, meaning slower load times.

    Further more, you can compress/minify a .js file, but you can’t compress/minify HTML (well, sort of, but not like Javascript).

  2. Anon says:

    Yawn. Inversion of control is so 2009.

  3. nagaozen says:

    I’ve been playing with Mootools Behavior and it really really seems to be, at least for me, the next big pattern in coding javascript. Although it doesn’t fit very well for web applications, where you are always injecting stuff dynamically, it’s BY FAR THE BEST way to work with a designers team to get a site up and running.

    Congrats MooTools!

  4. SJ says:

    I’m not sure I agree with this approach. I work on website with 45000+ pages and the additional page weight and bandwidth this would introduce could be substantial. I’m guessing there would also be a lot of redundancy where the same options are repeated on different pages? And with the redundancy comes the maintenance issue, changes can’t be made in a single location e.g. If I didn’t want tips any more, every anchor tag in the site would need updated.

    Could the same approach not be used with a single external JS configuration file?

    Cheers,

    SJ

  5. Tim says:

    Nice stuff Aaron! Thanks for the update.

  6. Htbaa says:

    Am I wrong to think this thing is similar to what Knockout JS is doing?

  7. aaron says:

    I should note that using data properties to capture UI configuration isn’t unique. There are some things unique to Behaviorjs - the delegator stuff I think is novel but not exactly rocket science - but you’ll find similar patterns in Dojo for example. Re: Knockout JS, I’m not 100% sure what their whole story is, but the inline stuff appears to be only a small part of it.

  8. aaron says:

    @SJ, it’s a balance question to me. We are always balancing bandwidth, performance, and development. Code patterns that make for easier development can have a big impact on building a better product at the cost of bandwidth or performance. If you optimize for performance that might mean a less interactive experience. What balance works for you and your product is something for you to decide.

    That said, I think that, unless you’re talking about a page with thousands of items that have this markup in them, the bandwidth change is likely to be minimal. Remember that these filters can work however you prefer. For example, a Tabs class doesn’t require you to mark up each tab and each section, but rather allows you to mark up the container of the elements with selectors to find those items. In the same manner, you could author a tips filter that is only instantiated once and runs a selector to find all the tip elements (like Tips in MooTools does now). It’s up to you.