Well, I commented out the whole code to the search page code which is only 146 lines. I know the editor performance is not associated with the logic in the search code. The search page layout and the logic behind the code is not complex and is so simple. I don’t mind sharing it here.
- Have a repeater for each database (about 25 or so in my case).
- Put each repeater in its own strip. Each strip has 1 text box which is a link and 1 repeater.
- When the user enters a query in the search box do the following
a) collapse all strips
b) cycle through each repeater and apply the filter which essentially checks 2 or 3 columns of the corresponding database using .contains(query). If the filter returns more than 0 items, expand that particular strip.
The reason to do it this way is to make sure that the search results will look exactly like the data you see on the other pages of the website.
Even the data displayed in each container of a repeater is straight forward. Most of them have about 2 images and 3 small lines of text (name, date, title).
I am trying to guess what is happening behind the scenes in the editor and why the performance degraded over night after Wix made changes to how repeaters are displayed in the editor.
I am suspecting that some editor code from editor X is shared back with the old editor. Editor X has to calculate layout based on a fluid model where as the old editor used to have a fixed or no-flow layout. When you try to move or expand a text box in the editor, it ends up recalculating the positions of everything that follows.
Another reason why I think the performance has deteriorated for the editor (and not for the final display of the webpage) is how repeaters are handled now in the editor. Now every repeater shows the first 12 items in the editor. In the past it used to show only one container and that also without the actual data from the database. This is a big problem. I have no idea why it has to display 12 items for each repeater during the editing process. Though the feedback loop will look cool for a small testcase, in the real world scenario where the actual data is getting filtered by the velo code, there is no need for the display of 12 containers for every repeater.
Just a simple calculation of what the wix edditor layout code had to go through in the past vs. now.
In the past:
Each repeater has 1 container with 3 images, 4 text boxes = approximately 10 rectangles.
Each strip (1 rectangle) with one text box (1 rectangle) and 1 repeater (10 rectangles) = 12 rectangles.
About 25 strips with 12 rectangles each = 300 rectangles.
Now with the new repeater layout:
Each repeater has 12 containers with 3 images, 4 text boxes each = approximately 120 rectangles.
Each strip (1 rectangle) with one text box (1 rectangle) and 1 repeater (100 rectangles) = 122 rectangles.
About 25 strips with 122 rectangles each = more than 3000 rectangles.
So now when you make a change to one small text box anywhere on the page, the editor goes through recalculating about 3000 rectangles instead of the 300 it used to do in the past. And the browser is not able to handle all the data for these 3000+ rectangles being moved especially when it has to communicate back and forth for every pixel moved. That is the reason why chrome crashes. I use Firefox. It doesn’t crash, but it basically comes to a crawl. To complicate this even further, the editor is actually accessing the 25 or so database contents to display all that 12 containers for each repeater. This is way overkill. And with async/await javascript code happening in the background in the layout manager code to do this, it can lead to async/await hell.
I know most of the programmers at Wix are much smarter and knowledgeable than myself when it comes to javascript coding. But all it takes is one newbie programmer who falls into the async/await trap and who puts async/await in a loop that calculates the layout for the editors layout manager. Maybe finding those bottlenecks is all that takes to fix the performance problem.
An example of this scenario is shown in the following article.
https://www.freecodecamp.org/news/avoiding-the-async-await-hell-c77a0fb71c4c/
A possible workaround or solution:
Give the website developer the option to decide whether they want 12 or 1 container for repeaters displayed during the editing process. Why hard code the number 12? Let the website developer set it in settings. If it is 1 container then don’t even bother looking at the actual contents of the database. Do it as it was done before.
Another workaround or solution:
Treat each strip like a black box during the editing process. Do not do any layout calculation for a strip if it is not the active one during the editing process. That way only one repeater will be active during the editing process at any given time.
