Infinity conflicts with liquid-fire about ember-infinity

[timohermans]

Well I fixed this issue with putting something extra in the selector:

scrollable="div.liquid-container div.velocity-animating div.scrollable"

I added div.liquid-container div.velocity-animating. DidInsertElement is triggered twice. Both times there's only one velocity-animating class present, which is nice.

The only issue that remains is that liquid fire destroys the scrollbar itself. It's not possible for me to scroll xD. Perhaps that's one other issue on its own.

[hhff]

Thanks @temo44 ! Liquid Fire does some wild stuff that I don't quite understand. @ef4 might be able to shed some light!

[ef4]

@temo44 is right about liquid-fire rendering multiple copies of your template. That is how we are able to animate between the old and new states with both states on screen at the same time.

It may take some tweaking of CSS properties, but I think you should be able to get this all working together.

[timohermans]

@ef4 @hhff Thanks guys. I fixed it.

I wanted the 'fade-in' animation to whatever page is being rendered after the login page. However, I wanted that fade-in over the whole page, not just the route(outlet) that was being rendered, after everything has been rendered.

So I took the custom animation example from the liquid fire tutorial page (http://ef4.github.io/liquid-fire/#/transitions/primitives). The only 'tweak' I thought that was necessary was that I put Ember.run.scheduleOnce('afterRender'.... around the animation of the new element.

So after this I started testing and the thing I mentioned about a cloned element occurred. Today, however, I noticed that the element won't be cloned when you do not animate the old element. And luckily for me, I don't even want to animate the old element :). So everything is fixed, without the use of css tweaks.

[hhff]

👍

[kellyselden]

@temo44 you might want to add a little "working with liquid-fire" section to the readme. I'm sure others will run into this at some point.

[hhff]

good point @kellyselden - just gave you push to this repo, btw

@temo44 - please hit us a with a lil PR for the readme!!

[timohermans]

Haha bear with me @kellyselden @hhff, I've a) never contributed to a project before(as in forking and then creating a pull request) and b) am in the middle of a relocation, so I've a little spare free time.

I'll try write up something in the weekends. Thanks! :)

[hhff]

no worries ❤️

[hhff]

@temo44 - wanted to see if you were still down to write a little section in the Readme explaining the problem and how you got around it? Supporting Liquid Fire is super important for us :)

[timohermans]

@hhff I will try to write my little piece tomorrow or the day after! We created a custom infinite scrolling solution so we're going to drop ember infinity in one of the upcoming releases I'm afraid.

I will try to check up on Infinity in my free time though!

[hhff]

all good @temo44 ! would love to properly understand your liquid fire fix regardless. Even if you post it here I can actually update the README

[timohermans]

Well, first of all I wanna apologize for the very late response. I've been really busy. Second of all, I have some bad news.

The last change that I did to our project was to just remove liquid-fire altogether. The reason for this is that in our use-case you could easily replace liquid-fire for pure css animation.

As you can read in my very first post, we used a liquid-if statement to make a transition over the entire page. However, we solved the whole duplicate element story by creating a normal if that adds a css class to the container that contains an animation. This makes the page look like it is fading in.

Now I know this won't solve the problem with normal liquid-fire transition and I'm sorry I can't be of any use in case. However, if we ever stumble across a problem like that. I will create another issue or PM @hhff. All I can say is that css animation can bring you a long way (also in terms of performance btw)

[hhff]

ok - thanks @temo44 !