CMS Load + CMS Sort and dynamic data

Attributes
,
1

Hey Luis!
Have a fun one for you, related to something we’ve explored in another thread about a year ago.

I’ll do a loom on this one to explain-

Test page-

https://show-nearest.webflow.io/

Codepen-

https://codepen.io/memetican/pen/vYQjzLm/e7b9dc532f9c872b346c70dab06a4755?editors=1010

2

Hey @memetican! This is interesting, is this the only code on the page? We seem to be having something triggering the list twice. Which can be some piece of code or a double script, but I can’t find either.

As you correctly said, this callback is fired when items are rendered and if you add it to your code, you’ll see it being called twice

listInstance.on('renderitems', (renderedItems) => {
  console.log(renderedItems);
});

Quick loom on what I found out :thinking:

3

Very interesting- I have the actual libraries loaded in Webflow;

<!-- [Attributes by Finsweet] CMS Load -->
<script async src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmsload@1/cmsload.js"></script>

<!-- [Attributes by Finsweet] CMS Sort -->
<script async src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmssort@1/cmssort.js"></script>

And I’m wondering if the lib is installing the webhooks and then my .init() is installing them again without removing the originals?

I tried doing this-

<!-- [Attributes by Finsweet] CMS Sort -->
<script async src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmssort@1/cmssort.js" fs-attributes-preventload='true'></script>

However CMS Sort just errors in that scenario.

Something interesting I noticed just now as I was retesting- my FS Load cache had expired ( I assume ), so Load needed to re-acquire the pages. That lead to a delay- I’d change the option, and see a refresh as sort tried to apply ( but had no km distance data? ), then after a good 1 to 2 seconds it would flash again sorted by kms.

That sort of validates my suspicion that the first sort is running immediately and the second one is running at the point of the init().

Can you recommend another configuration to try where FS Sort is only initialized once, at the init() point after the data is loaded? I was a bit surprised preventload didn’t do the trick, almost as it the first sort is still being attempted but since the library isn’t initialized it fails.

4

@memetican, you might be on the right track. I totally forgot the preventload yesterday.

However now that I was checking your setup, you seem to have a typo on the attribute tag. You added a 1 to the preventload attribute :eyes:

Can you test with the script below? I also changed the tag to defer which shouldn’t really affect much but I normally use this instead of async

<!-- [Attributes by Finsweet] CMS Sort -->
<script
  defer
  fs-attributes-preventload="true"
  src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmssort@1/cmssort.js"
></script>

This should fix the issue of the double init(). Again apologies for missing this detail yesterday haha

5

I did that because preventload was breaking the scripts entirely, and oddly before the cmssort init. Is it possible that putting preventload on cmssort also prevents loading of cmsload?

I’ve re-enabled it so that you can see.

My best guess is that enabling it on any script disables all FS attributes lib init()s and they must all be done manually.