Closed mixonic closed 8 years ago
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.
@mixonic I cleared the Travis cache and rekicked the build.
@mixonic Ah, the travis.yml needs to be updated.
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.
@mixonic Yeah, this works great with the demo app I was testing.
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.
Pushed the demo app to Heroku: https://ember-wormhole-fastboot-demo.herokuapp.com/
Onward!
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 https://github.com/yapplabs/ember-wormhole/issues/47 for discussion.
TODO:
isDestroyed
in theafterRender
callback.destinationElement
Document subclassing of the wormhole component classskipping this, but after merge and release I will open an issue/PR on the x-favicon repo