Purely functional feedback suppression?

Question

I have a problem that I can solve reasonably easy with classic imperative programming using state: I'm writing a co-browsing app that shares URL's between several nodes. The program has a module for communication that I call link and for browser handling that I call browser. Now when a URL arrives in link i use the browser module to tell the actual web browser to start loading the URL.

The actual browser will trigger the navigation detection that the incoming URL has started to load, and hence will immediately be presented as a candidate for sending to the other side. That must be avoided, since it would create an infinite loop of link-following to the same URL, along the line of the following (very conceptualized) pseudo-code (it's Javascript, but please consider that a somewhat irrelevant implementation detail):

actualWebBrowser.urlListen.gotURL(function(url) {
  // Browser delivered an URL
  browser.process(url);
});
link.receivedAnURL(function(url) {
  actualWebBrowser.loadURL(url); // will eventually trigger above listener
});

What I did first wast to store every incoming URL in browser and simply eat the URL immediately when it arrives, then remove it from a 'received' list in browser, along the lines of this:

browser.recents = {} // <--- mutable state
browser.recentsExpiry = 40000;

browser.doSend = function(url) {
  now = (new Date).getTime();
  link.sendURL(url); // <-- URL goes out on the network

  // Side-effect, mutating module state, clumsy clean up mechanism :(
  browser.recents[url] = now;
  setTimeout(function() { delete browser.recents[url] }, browser.recentsExpiry);

  return true;
}
browser.process = function(url) {
  if(/* sanity checks on `url`*/) {
    now = (new Date).getTime();
    var duplicate = browser.recents[url];
    if(! duplicate) return browser.doSend(url);
    if((now - duplicate_t) > browser.recentsExpiry) {
      return browser.doSend(url);
    }
    return false;
  }
}

It works but I'm a bit disappointed by my solution because of my habitual use of mutable state in browser. Is there a "Better Way (tm)" using immutable data structures/functional programming or the like for a situation like this?

Answer 1

A more functional approach to handling long-lived state is to use it as a parameter to a recursive function, and have one execution of the function responsible for handling a single "action" of some kind, then calling itself again with the new state.

F#'s MailboxProcessor is one example of this kind of approach. However it does depend on having the processing happen on an independent thread which isn't the same as the event-driven style of your code.

As you identify, the setTimeout in your code complicates the state management. One way you could simplify this out is to instead have browser.process filter out any timed-out URLs before it does anything else. That would also eliminate the need for the extra timeout check on the specific URL it is processing.

Even if you can't eliminate mutable state from your code entirely, you should think carefully about the scope and lifetime of that state.

For example might you want multiple independent browsers? If so you should think about how the recents set can be encapsulated to just belong to a single browser, so that you don't get collisions. Even if you don't need multiple ones for your actual application, this might help testability.

There are various ways you might keep the state private to a specific browser, depending in part on what features the language has available. For example in a language with objects a natural way would be to make it a private member of a browser object.