CSS Transition on conditional block

Questions
#1

Hi,

If I have something like:

 {{#if @category.categoryIsOpen}}
<li class="section1_furniture"> 
     <h3 class="instruction">{{this.instruction}}</h3>
     {{#if @showInstructionText}}
  
        <h3 class="next-step-instruction">
            <NextStepComponent 
                @placeholderText="{{this.nextstep_text}}"
                @onNextStep={{@onNextStep}}
                @category={{@category}}
                >
            </NextStepComponent>
        </h3>
    {{/if}}
     {{#each this.furniture as |furniture|}}
        <button class="section1-furniture-item" {{on "click" (fn @insertFurnitureItem furniture)}}>
            <div class="imgcontainer">
                <img class="furniture-image" 
                    title="{{furniture.id}}" 
                    src="{{root-url}}assets/arp/page_images/{{furniture.label_url}}"/> 
            </div>
            <div class="summary captionblock">
                <span class="label_image">{{furniture.caption}}</span>
            </div>
        </button>
     {{/each}}
</li>

{{/if}}

The whole block is conditional on @category.categoryIsOpen being truthy.

What is the generally accepted Ember.js way I can apply a CSS transition on the opacity as Ember.js shows it (to stop it ‘clunking’ into view)?

#2

One easy answer is to use ember-css-transitions, an addon which makes this easy with a straightforward API. If you want or need a higher degree of customization, you can just peek under the hood and see how that addon works and reimplement something similar yourself.

One basic way you could implement something, off the top of my head, is create a modifier (which by definition receives the element it’s applied to and would be run when element was inserted), which adds a class to the element and then schedules removal of that class and possibly adding other classes at later intervals. That could be as flexible as you needed, but you’d want to be careful about the implementation: depending on how you scheduled the later hooks, you could end up with memory leaks or “element does not exist” errors if you weren’t careful.

Notably, this is exactly the kind of API ember-css-transitions supplies!

1 Like
#3

Installed that, absolutely brilliant did just what I needed and more as well.

#4

Though I have this spitting out a lot:

css-transition.js:126 Uncaught (in promise) TypeError: Cannot read property ‘insertBefore’ of null at CssTransitionModifier.addClone (css-transition.js:126) at CssTransitionModifier.willRemove (css-transition.js:67) at ClassBasedModifierManager.destroyModifier (modifier-manager.js:38) at CustomModifierState.destroy (index.js:7052) at StringDestroyableDestructor.[DID_DROP] (util.js:355) at util.js:266 at Set.forEach () at didDestroyAssociated (util.js:265) at SimpleDestructor.[DID_DROP] (util.js:379) at util.js:304

#5

Remember how I said it would be easy to have problems during tear down? :joy: More seriously, I’d file an issue on the addon repo. This is a hard thing to get juuuust right, and a big report (especially with a clear reproduction) is invaluable.

#6

To be honest I usually avoid ember add-ons because 9/10 the bugs come thick and fast and it repeatedly seems not worth it.

There are a couple of well-known ones I do use like the power combo boxes for example. But most of them waste my time to be honest!

ember-css-transition seems really good apart from that crash

#7

I reported the issue and he’s closed it with a fix by the looks for it. Thanks

#8

Just want to comment now, that this issue is resolved now. It wasn’t the fix highlighted here but it has been fixed now.