Add ability to replace content instead of appending

[trentmwillis]

Didn't hear back about #48 so I figured I'd go ahead an implement it anyway, since it was quick to do.

[lukemelia]

@trentmwillis Thanks for working on this. What is the impact on the lifecycle hooks of the components rendered into the wormhole when content is replaced? It seems like the DOM would be removed without willDestroyElement being called on components previously rendered into the wormhole. I could be wrong though about this though. At the very least, perhaps we can have a test that clarifies this?

[trentmwillis]

@lukemelia I believe you are correct, though I hadn't considered that scenario. I can write a test to verify, but what is the desired behavior?

[lukemelia]

@trentmwillis Hmm, good question. It seems that your app would be in an odd situation where two wormholes targeting the same destination would result in only the contents of one of them being present. This seems pretty inconsistent with the Ember model. Maybe we need to rethink how to achieve your original goal.

[trentmwillis]

Our original goal is to be able to replace statically rendered HTML (not backed by a component) with a component's content (sort of like a poor man's rehydration). I can't think of a scenario under which we'd want to replace a component with another component, but that doesn't mean it couldn't happen.

I would suggest not removing content associated with another component, but that'll be difficult if the component happens to be tag-less. Maybe our manual removal of the static content is the correct approach for now...

[chrislopresto]

Just reading through this now. I kinda like this "hacky" rehydration scenario. And the implementation is pleasingly simple.

That said, competing wormholes targeting the same destination would cause problems. And there would indeed be general weirdness if the wormhole destination were to reside inside the Ember app's root element.

Perhaps the solution is to create a dedicated subclassed component that exhibits this behavior. That way anyone using a CloberringWormhole component could do so at their own peril. Whether this component belongs in ember-wormhole proper is separate question.

[lukemelia]

I'm inclined to keep this out of ember-wormhole until we all feel more comfortable that a good pattern has emerged of how to handle this.

[sdhull]

FWIW, this would occasionally be super-useful & I agree that the implementation is "pleasingly simple".

I'm honestly surprised no more discussion has taken place here in the past few years