Blank Repeater bug

I have about 40 repeaters on my custom webpage, all are hidden and collapsed. The problem is that ALL inexplicably ‘fly-in’ from the left when I execute the page. I set them to animate by a ‘fade-in’ with 0.1 latency and “only animate first time” set to off. That works for the first time they are shown. But when hidden and shown again, they fly-in from the left anyway despite the setting to off. How can I stop this behavior and turn animation off?

I thought I might have done something wrong. So as a minimalist test, I started a new page, added a button and a repeater. This is the repeater I am using…the blank one with horizontal repeats.

Then I added a text box inside the repeater and then set the repeater to hidden and collapsed. Here is the code to run the button:

$w . onReady ( function () {
$w ( ‘#button1’ ). onClick ( ( item ) => {
if ( $w ( ‘#repeater1’ ). isVisible ) {
$w ( ‘#repeater1’ ). hide ()
$w ( ‘#repeater1’ ). collapse ()
} else {
$w ( ‘#repeater1’ ). expand ()
$w ( ‘#repeater1’ ). show ()
}
})
});

Well, the thing does a fly-in from the left. So I am doing nothing wrong.

I search all through the Wix site and the forum to learn if this is supposed to fly-in. I found no such documentation and no complaints. Therefore it should not be flying in for me. Yet it does.

Wix, do you have a workaround to fix this bug? If not a bug, then what could be the problem? You can build the simple example as I have above and see what happens.

(I hope I put this posting in the correct place.)

I forgot to say I tried two other "blank repeater"s, the one with the vertical boxes does NOT fly-in so it is behaving correctly. The other one with the 4 boxes in it fly-in from the left as well.

Hi @jimyaccino ,
I’m also able to reproduce this. Thanks for discovering this strange behavior.
Please report the bug following the instructions described here: https://www.wix.com/velo/forum/coding-with-velo/how-to-report-a-bug-1

I think I have a workaround for my purposes. Each repeater has a text box located just above the repeater on the page. If I group then as a #group element, the repeater does NOT fly in. I will have to write mo=re code for this workaround, and I think it will be faster than waiting for development to verify and resolve a bug (I think).

I will try to submit a bug report tomorrow and then see what happens.

Does the same thing happen if you hide and show the repeater without collapsing it?

You might also be able to define a custom animation with the wix animations API. Doing so allows you to only play animations when you want. Just know that if you want to hide an element after an animation plays you have to pause the animation first.
Here is the documentation: wix-animations - Velo API Reference - Wix.com

And here is an example in code:

import wixAnimations from 'wix-animations'

let timeline = wixAnimations.timeline({
    "repeat" : 10,
    "repeatDelay" : 100,
    "yoyo" : true
})

$w.onReady(function() {
    let element = $w("#elementId")
    timeline.add(element, {animation you want to add (see docs)})
    
    //play timeline on initial page load
    timeline.replay()
})

// hide element with 
timeline.pause()
$w("#elementId").hide()

No, on my test page it does not fly-in in that case. Good to know that is not a bug. But for my web page purposes, the repeaters are intended to be expanded and collapsed. Without collapse, the page would explode as too long and user unfriendly.

In any case, I am NOT using animation anywhere on my test page. This appears to be a bug.

@marlowe-shaeffer I reported it. My workaround (discussed in below post) works but is cumbersome and after implementing my workaround, there appears now to be a different problem caused by the workaround. Please expedite this problem if you can. Thanks

@jimyaccino I would guess that the element is physically being remounted when it is expanded. It also looks like the expand function includes a built in animation. I do have a solution, but it will require a bit of work.

If you create a strip, attach the repeater to the strip, and resize the strip so it is exactly the same height as the repeater you can then collapse the strip instead of the repeater element. When you go to expand the element no animation will play.

The caveat here is that you will have to repeat this with all the repeaters you have (or copy paste the strip multiple times)

@amotor The workaround I noted above, to make a #group, works and took very little time to do on my page. Thanks for your consideration.

1 Like

It should be noted… You should not use hide and collapse at the same time.

If you want to “hide” an element, use either hide or collapse, not both.
If you want to “show” an element, use either show or expand, not both.

If you collapse an element, then use expand , not show.
If you hide an element, then use show , not expand.

You don’t want this:

    $w('#button1').onClick( (item) => {
        if ( $w('#repeater1').isVisible ) {
            $w('#repeater1').hide()
            $w('#repeater1').collapse()
        }   else {
            $w('#repeater1').expand()
            $w('#repeater1').show()
        }       
    })

You want either this:

    $w('#button1').onClick( (item) => {
        if ( $w('#repeater1').isVisible ) {
            $w('#repeater1').hide()
        }   else {
            $w('#repeater1').show()
        }       
    })

or this:

    $w('#button1').onClick( (item) => {
        if ( $w('#repeater1').isVisible ) {
            $w('#repeater1').collapse()
        }   else {
            $w('#repeater1').expand()
        }       
    })

@yisrael-wix thanks very much. It never occurred to me that using both is problematic. What problems do your forsee using both could cause?

@jimyaccino I would just say that it could cause unpredictable results. Perhaps stuff like flashing, messed up animation, a hangover - err, wait, that would be from mixing beer and wine (I heard that’s also not good)

But of course this will never get fixed because we too busy converting databases into spreadsheets so pipal can do 2+2 quick maths

What do you refer to by “… too busy converting databases into spreadsheets to do 2+2 quick math” ?

Well, at least Wix verified to me that two of the available stock repeaters display this bug. I presume it then hits their bug repair list. Unfortunately I am using one of the offending repeaters when I found the bug. My workaround to use Groups is gave me more headaches than I thought, which resulted in major changes to my code to handle it.

I would like to report that Wix Support suggested placing my repeaters inside Container Boxes. I did so, and had a lot of recoding to make them work, but that solved my problem. Cudos to Wix support for that suggestion.