Refactor to public APIs for head/tail

[mixonic]

In the template for ember-wormhole, use helpers that register an element to the parent wormhole component. The wormhole component can then use those elements to move to the target. This lessens the private APIs used by wormhole, but still uses private APIs to access the DOM or Fastboot SimpleDOM based on where the code is running. This could use all private API if we made SimpleDOM a dependency, but that would just inflate the JS payload with little benefit.

This unblocks Fastboot rendering. It will also mean dropping support for Ember versions before 1.13. See #47 for discussion.

TODO:

• Remove support for Ember pre-1.13
• Check for isDestroyed in the afterRender callback.
• Document Fastboot status
• Document/test passing a bare element to destinationElement
• Move SimpleDOM/DOM compat tooling to a util module
• Document subclassing of the wormhole component class skipping this, but after merge and release I will open an issue/PR on the x-favicon repo

[krisselden]

what is the registry thing solving?

[krisselden]

Nevermind, it is because this is before children are rendered, is there no hook on didCreateElement? I thought there was, anyway, I don't think this should be generic and use slots. Not only because this isn't very JIT friendly but because it is confusing like it is some general feature.

[mixonic]

didInsertElement is not fired for Fastboot. We kind of want a "fire all hooks I know what I'm doing" mode for Fastboot rendering. Doesn't seem likely. So instead we emulate the timing of didInsertElement using the hooks that do fire.

Regarding slots you suggest this should use an array instead? Would pre-defining the shape also be sufficient?

  init() {
    this._super(...arguments);
    this.wormholeNodeRegistry = { head: null, tail: null };
  },

[mixonic]

cool, refactored away from this.

[mixonic]

Another pass at the implementation here for review. @krisselden I did not refactor destinationElement away from being a CP. Can we punt that and the refactor away from observers to another pass?

The ember-try config here is updated, perhaps travis needs a cache flush.

I'll flesh out the docs changes later today.

[chrislopresto]

@mixonic I cleared the Travis cache and rekicked the build.

[chrislopresto]

@mixonic Ah, the travis.yml needs to be updated.

[mixonic]

This is pretty wrapped up- @bantic can you please confirm with your fastboot demo app that this PR functions correctly?

I'm actually quite curious what will happen upon initial re-render of the page. The idea for fastboot users might be that the nodes inside that part of the page are destroyed and re-rendered. But we should know what is happening for sure.

[bantic]

@mixonic Yeah, this works great with the demo app I was testing.

[lukemelia]

Nice work on this, all. Thanks for driving the implementation@mixonic! I'm +1 on merging and releasing 0.4.0 assuming @chrislopresto is as well.

[bantic]

Pushed the demo app to Heroku: https://ember-wormhole-fastboot-demo.herokuapp.com/

[chrislopresto]

@mixonic With the disclaimer that I haven't fastboot-ed, can you explain how this differs from:

{{unbound _firstNode ~}}
{{yield ~}}
{{unbound _lastNode ~}}

If these approaches are functionally equivalent, we could ditch the placeholder helper (and rename _firstNode and _lastNode to something more expressive).

[chrislopresto]

Onward!