.loadPage() getting floats despite passing whole numbers as its parameters: "currentPage method cannot be set to the value 1.75"

[briapril30]

While trying to debug, I have simplified and hardcoded it to go to page 2 of a dataset.

  $w('#productsList').onReady(function () {
    $w('#productsRepeater').onItemReady(productItemReady)
 // updateFilterSelectedN()
 // reloadProductsBasedOnFilter()
 // sortProducts()
    $w('#productsList').loadPage(2)
  })

When I load the page, I get this error in the developer console and it fails to load:

supplementaryErrorHandlers.js:22 Wix code SDK error: The currentPage parameter that is passed to the currentPage method cannot be set to the value 1.75. It must be of type integer,null. 

As you can see 2 is being passed into the loadPage() but developer console shows it receiving 1.75. If I pass in a 3 it spits an error saying it got 2.5.

If I set up a test button and have it perform the loadPage(pgNumber) it performs fine for some reason, but when I have it within the onReady function it doesn’t work at all.

[yisrael-wix]

Strange. One thing I noticed (which I don’t think makes any difference) is that you are defining the onItemReady() function inside the dataset onReady() function. It really should be in the page’s onReady() and not the dataset’s onReady(). Something like this:

$w('#productsRepeater').onItemReady(productItemReady)

$w('#productsList').onReady( function() {
   // updateFilterSelectedN()
   // reloadProductsBasedOnFilter()
   // sortProducts()
   $w('#productsList').loadPage(2)
})

If you’re still having issue, please post the URL of your site and explain where and how I can see the issue.

[briapril30]

@yisrael-wix Moved it outside but it didn’t do anything. However, I noticed that the number it reports is always y = x - 0.25x. So, if I hardcode 4, it says it got 3.25; 5 => 4; 6 => 4.75; etc.

For the float number issue just go to this link: https://briapril30.wixsite.com/website-3/shop
It is hardcoded with loadPage(2)

Like I said before, it works fine when the .loadPage() is assigned to a separate button so I thought it might have to do with my other functions working with the dataset, but when I try to finish all other functions before changing the page like so:

  $w('#productsList').onReady(function () {
    Promise.all([updateFilterSelectedN(), reloadProductsBasedOnFilter(), sortProducts()])
      .then(() => setPage())
      .catch((err) => console.log(err))
  })

I get this error:

Uncaught (in promise) r {code: "NO_SUCH_PAGE", message: "Page 4 does not exist", name: "DatasetError", stack: "DatasetError: Page 4 does not exist↵    at e.expor…services/dbsm-viewer-app/1.2624.0/app.js:6:103775", Symbol(error-boundary-scope): "userCodeZone", …}

For this error go to this link as long as p != 1 in the query ?p=, it will throw the uncaught promise error. so p=2, p=3, etc.
https://briapril30.wixsite.com/website-2/shop?p=2

Both of these are duplicates of this site (in the process of switching from lazy scroll to pagination, published site still uses lazy scroll) so if somehow the site itself is corrupted somehow, I need this site to be fixed.

Home | Miko.M | Hong Kong Online Jewelry Store

Thanks

[yisrael-wix]

@briapril30 I’m looking at it now. I see something interesting when I run the URL you posted (in Chrome):

A much different error message - but one that makes sense.

(Still looking at your site.)

[briapril30]

@yisrael-wix Really weird, I tried seeing if going to incognito mode would change anything and even tried going onto Edge and I still got the same thing as before for the 1st link.

However, the error you got seems to resemble the one I got for the 2nd link.

[yisrael-wix]

I noticed that you have a number of errors in your code. For example:

The WixDataSort API does not have the orderBy property. See the WixDataSort API for details. You’ll need to fix these errors, as well as the errors in the other files and pages. Some of the errors occur in the Public code files since the $w namespace is not accessible from these files. You’ll have to reorganize your code to adjust for this.

[briapril30]

@yisrael-wix Those red errors didn’t show up until today. A multitude of those ‘errors’ aren’t even actual errors, considering it was fine before and everything else still works as intended.

For example, the orderBy isn’t technically part of the WixDataSortAPI, but it is literally part of the sort object that wixData.sort() returns. The ascending() and descending() functions just adds to the array in orderBy.

Also you say “$w namespace is not accessible from these files”, yet 90% of the my code I have organized into chunks that deal with specific parts or functions of that page (ie: code load the filter options, code that dictate what to do when those filter options are interacted with) and it works fine on the main site (the duplicates may have some issues since I haven’t finished changing some stuff to account for pagination since I ran into the whole 2=1.75 issue). Can you explain how it is not accessible from those files? If it were truly not accessible shouldn’t they be unable to fill out those menu options, expand/hide those elements, etc.?

[yisrael-wix]

@briapril30 If orderBy “isn’t technically part of the WixDataSortAPI”, then it is not guaranteed to work, and most probably won’t work, the way that you intend.

In this code screenshot:

filter.filterTree.$and may be part of the filter object, but it is not part of the documented and supported API, and won’t necessarily work the way that you intend. The way to create a filter is through the documented API functions and properties.

$w(‘#productsList’), $w(‘#loadingAnimation’), $w(‘#productsRepeater’), $(‘#noItemsFoundBox’), and other page elements, are not accessible from a public file. Page elements (the $w namespace) are only accessible from page code and from the global masterPage.js file.

[briapril30]

@yisrael-wix So I found out the initial issue was fixed with an ‘await’ during the filtering of the dataset. Although it doesn’t explain the floating error, it was basically unable to load the page because it wasn’t done filtering so the dataset was I guess empty?

Related Issue
However, I noticed a different issue related to the current objective (switching from a lazy scrolling to pagination). The pagination element essentially disappears with an error regarding ‘getBoundingClientRect’ under certain circumstances (outlined at below). I don’t have any code that collapses or hides the pagination element, which is the weird part. So I went back and changed the orderBy and filterTree methods to the one’s described in the API, but the issue still remains.

https://briapril30.wixsite.com/website-3/shop?p=5
Steps to Reproduce:

1. Go to any page greater than 1 (can just click the link)

2. Filter dataset (pagination still present)

3. Deselect filter (pagination disappears and throws error)

I have tried both with the pagination linked to the dataSet as well as unlinked and both have the same issue. With it unlinked, it seems the error gets thrown sometime around when it changes $w(‘#pagination’).totalPages. If you skip assigning a new value to totalPages it does not throw an error at all and it doesn’t disappear, however not assigning a new totalPages is not practical.

Additional Question Regarding Public Files
Could you explain what you mean by those elements “are not accessible from a public file”? For example when I call a function that calls $w(’ #loadingAnimation ').expand() from those public files it expands. I don’t get how they “are not accessible” from those public files when it interacts with those elements just as it should. Another example, like I said before, I have a public file just for loading the filter options into the filter menu on the left and the following repeater is loaded from exported function from a public file. If they “are not accessible” how are they manipulating the repeater and furthermore retrieving information from those repeaters when choosing an option from those repeaters?

export function loadFilters(){
 var filterObj = JSON.parse(session.getItem('filterObj'))
  [...]
  loadSetColor(filterObj)
}
function loadSetColor(filterObj){
  $w('#setColorRepeater').onItemReady(($item, itemData, index) => {
    setColorOptionsItemReady($item, itemData, index, filterObj)
  })
  wixData.query('MyStore')
    .limit(100)
    .distinct('setColor')
    .then ((result) => {
      $w('#setColorRepeater').data = result.items.sort(function(a,b){
        return sortColors(a, b)
      })
 if(filterObj.setColor.length > 0){
        $w('#setColorContainer').expand()
        $w('#setColorShowIcon').hide()
        $w('#setColorHideIcon').show()
      }
  })
  setFilterTitleNumber('setColor', filterObj.setColor)
}

[yisrael-wix]

Hey @briapril30 , I didn’t forget about you. I was trying to clear up the issue of public files. And it’s like this…

The masterPage.js file is if you want to add processing for your header or footer, and to handle elements that you want to put on every page (with the same element ID). This file has its own onReady() event handler.

The main idea behind Public code files is for code reuse . The Public section is where you put JavaScript files that contain the code you want to use on multiple pages in your site, without having to include the code on each page. As with the masterPage.js file, you can access page elements from Public files. The problem is that you can’t be sure from which page the Public files are used and it follows that you can’t be sure which components are available on the page. So, while it is possible, it is not encouraged.

The masterPage.js file and Public files, are intended for different uses, but are similar in that they both have the same scope, and that you can access page elements from both types of files. For Public code, best practice is to pass the elements from the page code to the public files .

Cheers

[briapril30]

@yisrael-wix Thanks for your response. I am guessing what you said about masterPage.js is the same as page.js (ie: shop.js) considering I don’t think I have anything in masterPage.js? Sorry to be pestering with you so much.

Background
One of the main reasons I organized it the way I did was because I wanted the mobile version of my site to have the filter elements on a lightbox instead of cluttering up the page. So I copied those elements into a lightbox and essentially a lot of the code that dealt with the filters (ie: loading, onClick, etc.) would have to be duplicated so I decided to just put them in their own page and import them. After doing that I found that it also made the code easier to manage as everything related to certain aspects were in their contained files especially since the Wix editor expands every function whenever I open it making it a bit cluttered.
Follow up
“The problem is that you can’t be sure from which page the Public files are used and it follows that you can’t be sure which components are available on the page.” As long as I am keeping track of those $w I’m fine right? The benefits of keeping things more organized in their own files heavily outweigh the small chance that I try to use the $w on an element that doesn’t exist on a certain page. The only time it happened to me was when it was a mobile page and those elements were hidden in the mobile version; I fixed it with form===mobile or whatever, but in that case I think it would have had an issue even if the code was directly in the page.js file anyways .

Regarding the ‘getBoundingClientRect’ issue after using filters/pagination
Steps to Reproduce:

1. Go to any page greater than 1 (can just click the link)

2. Filter dataset (pagination still present)

3. Deselect filter (pagination disappears and throws error)
   I was able to the fix the issue I mentioned in the previous post by just adding a line of code that would execute when the user tries to filter the dataset so that it loads back to page 1 before actually filtering the dataset. However it may be something for QA to look into as I was able to narrow the issue down to it occurring when trying to change $w(’ #pagination ').totalPages.
   Thanks