di-9.js

// tests/helpers/dummy-component.js

import Ember from 'ember';

const {
  Component,
  assign,
  getOwner
} = Ember;

export function registerDummyComponent(context, name = 'dummy-component', opts = {}) {
  let owner = getOwner(context);
  let options = assign({ tagName: 'dummy' }, opts);
  let DummyComponent = Component.extend(options);

  unregisterDummyComponent(context);
  owner.register(`component:${name}`, DummyComponent);
}

export function unregisterDummyComponent(context, name = 'dummy-component') {
  let owner = getOwner(context);

  if (owner.resolveRegistration(`component:${name}`)) {
    owner.unregister(`component:${name}`);
  }
}

Hi I recently read your DI article and had a question about line #16 which calls unregisterDummyComponent(context); before registering the component.

I'm not familiar with testing components, maybe this is a known convention but it looked strange because it seems like like this call would always do nothing. The owner.register(component:${name}, DummyComponent); has not executed yet, meaning the if statement would attempt to resolve something that has not been registered yet and return false.
The only other conclusion was that this must have been a work-around for to protect against the dummy component being registered multiple times. Guessing the subsequent calls to registerDummyComponent will unregister and reregister ensuring there is only ever one registered. However, if this was the use case, it seems like there would be easier alternative which would be to add if statement around the owner.register to only call if the resolveRegistration is false.

Anyways, Great article! I always liked thinking about components as function programming for GUI, with their natural composition via nesting, and partial application using component helper / hash which is similar to currying and always generating the same HTML output for given inputs. The article is a great example to reinforce the concepts.