[SOLVED] The Event Context of the repeater is not returning the correct Item Id

Ask the community
,
1

I have been working with repeaters for some time, and recently I have encountered an error in the event context when using OnClick functions, to avoid duplication of OnClick Funtions I’m using the following example: https://www.wix.com/velo/reference/$w/repeater/introduction#$w_repeater_introduction_repeated-item-scope.

Following the example I add this to my code:

let clickedItemData = data.find(item => item._id === event.context.itemId);

event.context.itemId should return the ID of the item, in this case is the same ID as the one saved in a Collection so for example “53a57176-b52d-4b3d-b5e6-887c22822e32”.
However recently the event.context is returning something like “item-kqkkmq3” which doesn’t make sense. The data that I’m assigning to the repeater already has the “._id” property and it doesn’t match the one that I’m getting.

This only happens with the live version of my website, but it doesn’t happen all the time.

1 Like
2

Update: I discovered that if the repeater is filled with items before using data to populate it, the items sort of remember the old Id, and don’t change it to the new Id, maybe is because the OnClick function is running before the repeater is populated?

Update 2: When a repeater is filled a second time, the ID of the item changes and the repeater automatically ads something like “_p2_p3” at the end of the ID of the item, in the context

3

I have the same problem. My code used to work correctly until a week or so ago. But now I have the same problem. I have put a work around as follows. But this bug is a serious bug and hard for most people to trace. It does not happen on the first try. But from the second time onwards.

You can try out my sample site isolating this bug. Click on one of the items in the repeater. It should show only the matching lines. Then do a ‘Show All’ and do another one. If you click on the same item as before it does not add the 'p’ to the id. But if you click on any of the other items, then those itemIds have the p at the end.

https://svwoodturners.wixsite.com/repeaterbug

import wixData from ‘wix-data’ ;

$w . onReady ( function () {
$w ( “#foo” ). onClick (( event ) => {
let itemId = event . context . itemId ;
itemId = bugfix ( itemId );
let data = $w ( “#fooRepeater” ). data ;
let itemData = data . find (( item ) => item . _id === itemId );
if ( itemData !== undefined ) {
$w ( ‘#barDS’ ). setFilter ( wixData . filter (). eq ( ‘title’ , itemData . title ));
}
})
});

export function showAllBtn_click ( event ) {
$w ( ‘#barDS’ ). setFilter ( wixData . filter ())
. then (() => $w ( ‘#barDS’ ). refresh ())
}

function bugfix ( itemId ) {
console . log ( 'itemId before fix = ’ , itemId );
let i = itemId . indexOf ( ‘p’ );
if ( i !== - 1 ) {
console . log ( ‘***** BUG ***** the itemId should not end in p* . This is a bug in repeater code.’ )
itemId = itemId . substr ( 0 , i );
}
console . log ( 'itemId after fix = ’ , itemId );
console . log ( ‘-------------------------’ );
return itemId ;
}

4

I have reported this problem here and provided a simple temporary fix/wordaround.

5

Thanks for reporting. We’ll let you know when the issue is resolved.

6

Yeah, I also have a workaround, Since Wix uses 36 characters as an Id for the collection items I just slice the id like this:

let clickedItemData = $w("#repeater").data.find(item = item._id === e.context.itemId.slice(0,36);

However this only works with this bug specifically, I’m also getting a completely different Id when clicking the first item in the repeater, something like “item_kkqkkq” which is the ID that Wix gives to the items you added manually to the repeater and not the one you assign with code.

7

Hi everyone,

Thanks for sharing your workarounds. Our dev team is working on a solution, and we will provide an update as soon as more information is available. Thanks for your patience!

8 
I have this same problem, when I perform one or two searches in the database it happens with the repeater that mixes the Ids
9

This issue is now resolved. Please let us know if you continue to experience any problems. Thanks!

10

@marlowe-shaeffer I continue to experience the problem of mixed IDs, The context is still returning the incorrect ID “item-kqmqnq3q” instead of the correct one “53a57176-b52d-4b3d-b5e6-887c22822e32”
Edit: and still the ID has the “_p_2” at the end when the repeater is refilled with new data.

11

@developer84924 Have you republished your site since we deployed the fix? You might be seeing an old, cached version.

Can you please share the URL for your site so we can investigate? Thanks.

12

@marlowe-shaeffer Yeah I already published the site and tried clearing my cache.

https://pablo55557.wixsite.com/balmtattoo/aftercare-new

To replicate the bug click on the image of the first item while the developer console is open and you should be able to see the incorrect id.

13

@developer84924 Update: We had to revert the fix because it caused new regressions. I’ll let you know once it’s resolved. Sorry for the inconvenience!

14

We investigated your site, and you’re experiencing a different bug. We have a ticket open on this issue and I’ll let you know when it’s resolved.

15

Hi @marlowe-shaeffer has this issue been resolved yet please? A bit confused with your response above regarding a different bug.

16

@marlowe-shaeffer Hello!, could you please explain what bug are you trying to solve and what bugs are currently resolved?, The original post has information on 2 bugs, one when the context returns a completely different id than the one you assign, and the other when the context returns the correct id but also adds “p” at the end. Thank you

17

@developer84924 Both bugs should now be resolved; we just rolled out fixes a few minutes ago. If a new issue arises, or an old one presents itself, please create a new post for each issue (to avoid confusion) and tag me. Thanks.