Slight delay in removing components when transitioning

[adamhong]

I've noticed there is a slight delay in elsewhere components being removed from the DOM when transitioning. We're using a workaround on willTransition route hook to handle this for now.

[ef4]

Yes, ember-elsewhere generally requires two render passes. That's the only way to safely make the act of rendering one template alter the content of another (and it needs to be done carefully to avoid arbitrarily large performance impact and/or backtracking re-render assertions).

Generally this is ok, since glimmer's updating VM is extremely efficiently, so the second render doesn't cause much extra work. It does mean there is a possibility that the browser will actually paint the intermediate state and it could be perceptible under some conditions.

I am open to exploring ways to avoid the second render. There are possible solutions, but they would all require support deeper down inside the glimmer virtual machine.

[sheldonbaker]

I think I've been bitten by this too:

{{#if buyerToEdit}}
  {{to-elsewhere named="modal" send=(hash
    modal=(component "buyer-editor"
      buyer=buyerToEdit
      save=(pipe-action (action saveBuyer) (action (mut buyerToEdit) null))
    )
    close=(action (mut buyerToEdit) null)
  )}}
{{/if}}

{{#from-elsewhere name="modal" as |sent|}}
  {{#if sent}}
    {{#modal-dialog}}
      {{component sent.modal close=sent.close}}
    {{/modal-dialog}}
  {{/if}}
{{/from-elsewhere}}

After my save action finishes, and buyerToEdit is null, the buyer-editor component remains in the DOM, albeit with a now-null buyer object. Is there a way around this aside from explicitly checking inside the buyer-editor component?