Cleaning up Resources using MutationObserver

Cleaning up resources?

Let’s say you’ve written a shiny new component in your favorite framework and somewhere along the way you’ve allocated a resource that cannot be automatically cleaned up by the browser.

Maybe you attached an event handler to the resize event on the window.  Maybe you passed a callback to a global object.  Whatever the case, you need to tidy up those resources at some point.

Easy enough, right?  Put a dispose method on our object to clean up it’s leftovers and make sure it’s called before the object is discarded.

Problem solved?

Problem not quite solved

What if, for whatever reason, your component doesn’t have control over the parent?  You could trust that the user will do the right thing and call dispose for you but you can’t guarantee it.

As an alternative, can we automatically clean up our resources as soon as our containing DOM element is removed?

Yes.  Yes we can.

Using MutationObserver

The MutationObserver API (which has pretty great browser support) lets you listen to changes made to a DOM node and react to it.  We can use it here to perform our cleanup.

When we create an instance of MutationObserver we specify a callback that gets details of changes made to the parent.  If those changes include the removal of our target element then we can call dispose.

Here we are observing the parent of our target node, not the node itself (which would not be notified if removed).  We need to specify { childList: true } as the second parameter to be notified of additions and removals of child items.

Disposing the Observer

Finally, we need to make sure that the observer itself doesn’t cause a memory leak!  The observer is connected to the parentElement which (we assume) will still be hanging around, so we need to make sure that we disconnect it as part of disposal.

With everything pulled together the final version looks like this…


Moq-ing Dynamics

This post serves as a reminder to myself…largely because I have wasted time tracking this down twice now!

When you are mocking an interface that returns a dynamic object, moq is (as ever) your friend

public interface ISomething {
    dynamic GetSomething();

Using the standard moq syntax, you can very easily mock this call to return a real object..

    var theThing = new Mock<ISomething>();
    var mockInstance = new SomeMockClass();
    theThing,Setup(t => t.GetSomething()).Returns(mockInstance);

This is a pretty common pattern, but there’s an important gotcha to note: if you the C# runtime binder can’t see the type SomeMockClass then when your target code tries to evaluate the return value you’re going to get an error…

    'object' does not something something about GetSomething()

But you aren’t returning an instance of object are you. So why can’t it work out what you’re aiming for?

Turns out that it’s pretty simple. For the dynamic binder to pick up your mock type, it has to be able to see the type. Is your mock type publicly visible? Thought not.

Make your private mock class publicly visible and suddenly the runtime binder knows what you’re talking about!

Autofac and Async Resources

I came across a problem on a recent WebAPI project where I wanted to use Autofac to inject some tenant information (i.e. derived per request) into the constructor of each controller:

public class MyController : ApiController
  public MyController(TenantInformation tenantInfo)

The problem was that the TenantInformation had to be sourced from an async API call

var tenantInfo = await tenantApi.GetTenantInfoAsync();

This means that you cannot implement something like the below to register the component

static void Main(string[] args)
  var builder = new ContainerBuilder();

  builder.Register(context => context.Resolve<TenantApi>().GetTenantInfo());

  var container = builder.Build();
  var example = container.Resolve<ExampleController>();
  // --> throws 'Autofac.Core.Registration.ComponentNotRegisteredException'

On closer examination of container we can see that TenantInfo has not been registered; instead we have registered an instance of Task<TenantInfo>.  We can await this but not from a constructor.
One option that I briefly considered was importing the service directly into each controller and then getting the value within each async action method that required it.  This works but it feels messy and against the point of DI.  I want to be able to depend on my dependencies; not on the providers of my dependencies.

Using a Mediator

My solution was to create a mediator object representing an asynchronously-resolved component:

interface IAsyncRegistration
  Task Resolve(IComponentContext context);

class AsyncRegistration<T> : IAsyncRegistration
  private Func<IComponentContext, Task<T>> _resolve;

  public AsyncRegistration(Func<IComponentContext, Task<T>> resolve)
    _resolve = resolve;

  public bool Resolved { get; private set; }

  public T Value { get; private set; }

  public async Task Resolve(IComponentContext context)
    this.Value = await _resolve(context);
    this.Resolved = true;

This class wraps an resolution function for the type, the resolved value and a flag to indicate whether or not it has been resolved. It also implements a non-generic interface so we can find all instances of AsyncRegistration<T> regardless of T.

public static IRegistrationBuilder<T, SimpleActivatorData, SingleRegistrationStyle> RegisterAsync<T>(this ContainerBuilder builder, Func<IComponentContext, Task<T>> resolve)
  builder.RegisterInstance(new AsyncRegistration<T>(resolve))

  return builder.Register<T>(context =>
    var asyncRegistration = context.Resolve<AsyncRegistration<T>>();
    if (!asyncRegistration.Resolved)
      throw new DependencyResolutionException($"Async component {typeof(T).Name} has not been resolved");

    return asyncRegistration.Value;

Next I created an extension method for ContainerBuilder that adds 2 registrations:

  1. A registration of AsyncRegistration<T>
  2. A registration of <T> that resolves the AsyncRegistration<T>, checks that it has been resolved and then returns the result

Finally I created an extension method that can be called on the container from anywhere within an async block that will resolve all of the values

public static Task ResolveAsyncRegistrations(this IComponentContext context)
  var registrations = context.Resolve<IEnumerable<IAsyncRegistration>>();
  return Task.WhenAll(registrations.Select(r => r.Resolve(context)));

All together this means that the following will work and we can now inject asynchronously-resolved services into controller constructors:

var builder = new ContainerBuilder();
builder.RegisterAsync(context =&gt; context.Resolve&lt;TenantApi&gt;().GetTenantInfo());

var container = builder.Build();

// an async block...
await container.ResolveAsyncRegistrations();

//...then some time later...
var tenantInfo = container.Resolve<TenantInfo>();

Plugging in to WebAPI

The easiest way to plug this in to the WebAPI pipeline is to create a message handler that

  1. Gets an IComponentContext for the current request
  2. awaits a call to the ResolveAsyncRegistrations extension method
public class AsyncRegistrationHandler : DelegatingHandler
  protected override async Task&lt;HttpResponseMessage&gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    var scope = request.GetDependencyScope().GetRequestLifetimeScope();
    await scope.RegisterAsyncComponents();

    return await base.SendAsync(request, cancellationToken);


This system works for my particular scenario but there are a lot of possible situations where this would not work or would need extending.  The lifetime management of the dependencies, for example, is very rigid in this implementation and would need some work to be exposed properly.

Individual isEditable support in has supported both individual (ko.editable(...)) and object-level (ko.makeEditable(target)) editable implementations for some time but the 2 implementations differ slightly. The object-level version supports a per-object isEditable value to enable or disable the beginEdit call but this has previously been absent from the individual implementation.

From version 0.0.25 this is now supported.

var value = ko.editable();
value.isEditable = ko.observable(true); //or ko.computed, or raw value
value.beginEdit(); //has no effect
value.isEditing(); // --> false

As with the object-level version, any one of a raw value, observable value or computed value is supported and will be re-evaluated whenever beginEdit is called.


Sorting in KnockoutJS with

I have just finished working on some new functionality in to allow easy sorting of observable collections.  The key features are:

  • Ability to sort collections on properties and property paths
  • Live sorting that reflects changes to observable properties
  • Binding handlers to drop in sorting functionality in tables

The full documentation is available on GitHub ( but let’s take a look at some of the features here.

Basic Sorting

The sortable functionality is implemented using an extender so it can be applied to any observableArray in one line:

var myCollection = ko.observableArray([3,1,2])
                     .extend({ sortable: true });

// myCollection -> [1, 2, 3]

Without specifying any options the extender will simply sort based on the value using standard JavaScript sort mechanism.

Property Sorting

A more common use case is to sort based on a property of each object in the collection.

var myCollection = ko.observableArray([
  { id: 1, user: { name: ‘Bob’ } },
  { id: 2, user: name: ‘Adam’  } },
  { id: 3, user: { name: ‘Charlie’  } }
  sortable: {
    key: ‘’

The key specified can be any valid property name or property path to access the value on which to sort.  In the above example, the collection will be sorted by the name of the user property on each object.

Observable Properties

If any of the properties in the specified path are observable then these will be used for the sorting and they will react to any changes to the property.

function ItemModel(name) { = ko.observable(name);

var myCollection =ko.observableArray([
  new ItemModel(‘Adam’),
  new ItemModel(‘Bob’),
  new ItemModel(‘Charlie’)


// myCollection -> [‘Bob’, ‘Charlie’, ‘Dave’]

Binding Handlers includes a new binding handler to assist in sorting a collection on different keys (as would be the case in a table).

			<th data-bind="sortBy: { source: myCollection, key: 'name' }">Name</th>
			<th data-bind="sortBy: { source: myCollection, key: 'age' }">Age</th>
	<tbody data-bind="foreach: myCollection">
		<!-- etc -->

The binding handler has 2 effects:

  1. Attach a click handler to sort on the specified key when the element is clicked
  2. Inject a caret as a child of the element to indicate what sorting is being applied, if any