2/10/2014

Enyo Observables: Making kinds self-sufficient

These are exciting times in the Enyo world; Enyo is soon to release version 2.4. This is an extremely important release that brings MV* features and a host of language improvements. I am going to discuss a feature new to Enyo called "Observables", and the power it has when combined with Enyo's inheritance model.

Observables are a powerful tool for controlling an object's functionality. Although new to Eyno, observables are not a new idea and are implemented in other frameworks. The use of an observable is a simple idea. You create an object, then decide to watch a property on that object. The observable code is fired whenever the property is changed through a setter method. This allows for even finer modulariztion of code than normally possible. Functionality can be tied to the affected object directly. Functions and objects outside the object no longer need to understand how it should work.

Let's create a simple form with an audit trail. Without Observables, we would most likely have an event handler at the document or field level to update the audit trail when the fields change. With Observables, we are going to update the audit trail when a particular object property changes. The function bound by the observable will know how to update the audit trail. The event handlers are only going to tell the application object to change a single property value.

The form will consist of:

  • Input field
  • Repeater (The repeater is pulling data from a collection, and the bind object details that relationship. Binding is another feature coming to Enyo that I won't be discussing here)
The structure of the form is defined as follows:

enyo.ready(function () {
    enyo.kind({
        name: 'Area',
        kind: enyo.Control,
        title: 'Observable Test',
        dirty: false,
        modified: 0,
        lastModified: '',
        observers: {
            processDirty: ['dirty']
        },
        rendered: function () {
            this.inherited(arguments);
            this.$.repeater.set('collection', new enyo.Collection());
        },
        components: [{
            tag: 'span',
        }, {
            tag: 'br'
        }, {
            kind: enyo.Input,
            onchange: 'markDirty'
        }, {
            name: 'repeater',
            kind: enyo.DataRepeater,
            components: [{
                components: [{
                    name: 'item',
                    tag: 'li'
                }],
                bindings: [{
                    from: ".model.message",
                    to: ".$.item.content"
                }]
            }]
        }, {
            name: 'counter',
            tag: 'span',
            content: 'Modified 0 times.'
        }]
    });
});

There are two important pieces to notice in the above. The property we are going to use as our flag is the "dirty" property. The observable will be watching for when dirty's value is changed, perform an operation, and then reset the field to false. The second piece is the observers clause (processDirty: ['dirty']). The key is a function name, and the value array contains the property(s) on the kind that will fire the event when changed. The processDirty function will look like this:

 
    processDirty: function () {
           if (this.lastModified) {
                this.$.repeater.collection.add({
                    message: this.lastModified + ' modified on ' + new Date()
                });
            }
            this.$.counter.setContent('Modified ' + (++this.modified) + ' times.');
            this.lastModified = '';
            this.dirty = false;
        }
 

This function updates the fields who are linked in functionality to the "dirty" property of the kind. First it checks to see if the kind has a valid date in the lastModified property. If so, then it adds a line of text to the repeater's collection. The collection is an EnyoCollection to which the DataRepeater is bound. The repeater reflects in the UI what is stored in the collection. The result is that the front end will update the UI with the latest addition.

The final piece to tie this all together is to have the text fields change the "dirty" property. The function that will make this change is called "markDirty". Notice that the Input component has an onchange handler. Onchange is an event that Enyo Controls automatically fire, so identifying the "markDirty" function is all that is required. The markDirty function uses setter methods to set the properties. This is an important point. Observables only work when using the setter method. Changing the property directly will not cause the Observable to fire. The function looks like this:


        markDirty: function (inSender) {
            inSender.owner.set('lastModified', inSender.id);
            inSender.owner.set('dirty', true);
            return true;
        }

Observables are a powerful tool in every language they appear, including Enyo. One feature that Enyo has that makes this even more powerful is it's inheritance model. We can create a child kind from this kind and have that function run automatically. In practical terms, you can set a base set of operations for all your like controls. In the UI, you can create children that are adapted to meet that UI's needs, however, all of them are guaranteed to share a set of common operations.

For example, we will create a child of the above example. It will function almost exactly like the parent however, we want to enhance the observer function. Let's say entering data in the child is dangerous and we want to notify the user. We use this.inherited to call the parent observer function and update the audit trail, then we will add an alert specifically for this field:


    enyo.kind({
        kind: 'Area',
        name: 'AreaChild',
        processDirty: function () {
            this.inherited(arguments);
            alert('This is a serious change');
        }
    });
The child uses all of the parent's functionality, and only adds it's own flavor to the existing template. Now when the user changes the child kind field the audit trail is updated, and an alert warning the user is fired. Combining Observables and inheritance would allow a developer, or a group of developers, to create a common set of objects to work from. A toolbox of well crafted objects can create a strong foundation for all applications to inherit from.

All code can be found at http://jsfiddle.net/dposin/spj7q/