Tag: design patterns

I thought it’d be interesting to consider Javascript objects which can modify their own behavior over time. A use case for this (what I’m doing) is pages of data, where data is first looked up, then cached in memory, then cleared. A simple case (demonstrated below) is memoization.

The following query will do an ajax lookup of some data:

function loadData() {
  var data;

  $.ajax({
    url: "blocks/" + this.block,
    async: false
  }).done(function(blockData) {
    data = blockData.split("\n")
    for (var i = 0; i < data.length; i++) {
      data[i] = data[i].split("\t")
    }
  });

  return data;
}

var x = {block: 'xabnh', getData: loadData}

x.getData();
Array[2501]

This shows how one might trigger caching the results. Once retrieved, the cached data is hidden within a closure, and the mechanism for retrieving data is updated. In the case of a memory manager, these pages are later cleared out by replacing the memoization function with a third function, which starts the process all over again.

var x = {block: 'xabnh', getData: memoize(loadData)}

function memoize(getData) {
  return function() {
    console.log('loading');
    var data = getData.apply(this);
    function savedData() {
      console.log('memoized');
      return data;
    }
    this.getData = savedData;
  
    return data;
  }
}

x.getData()
loading
Array[2501]
x.getData()
memoized
Array[2501]

There are a few downsides to this approach; data in the closure is hidden from inspection, the current state of the object is hidden, and can change quickly. A generalized approach to this problem might pass an object into the getData function to show state or trigger a debug mode.