Fix for https://github.com/cibernox/ember-basic-dropdown/issues/615

[ducharmemp]

Fixes #615 🤞

I noticed that as of 1819c01#diff-73297f8c71645544a2a6826e5c3146aff7cb2333d9c17fe968258e5f14dc4a79R164 the animationClass was set to transitionedInClass when animating out. I set this back to the original value, and also reordered the calls to preemptively set the state on transitioning out, regardless if the parent element exists. I think this is correct because no matter what the reason (barring animation disabled), on a transition out we want to be able to render with the correct value when the drop down enters the dom again.

[ducharmemp]

Note that on the preview site, animation out is still semi-broken. Not sure exactly why but I have a hunch that will-destroy is getting called in the template after the parent node has been removed from the DOM, so we're exiting the function early. Local testing confirms this is the case but I'm not sure how or why considering the docs say it'll be called before all that happens.

https://github.com/emberjs/ember-render-modifiers/blob/master/addon/modifiers/will-destroy.js#L4-L5

[ducharmemp]

Not sure if this is the right fix, but what I was seeing is that the parentElement was always null on will-destroy calls. However, since we want to animate at the destination location I think this is right? Not sure 🤷‍♂️

[emilkarl]

Seems like this fix isn’t working if you are using renderInPlace but not sure?

[ducharmemp]

Seems like this fix isn’t working if you are using renderInPlace but not sure?

You might be right, I can't remember if I tested with render in place. I'll give it a look this evening

[dardalan]

Hey @ducharmemp! Any updates on this issue?

[dardalan]

@ducharmemp @emilkarl imho, it should be just enough to revert this, am i right?
1819c01#diff-73297f8c71645544a2a6826e5c3146aff7cb2333d9c17fe968258e5f14dc4a79R164

this.animationClass = this.transitionedInClass;
change to 
this.animationClass = this.transitioningInClass;