Encountered a strange thing. I have a page where the client can leave their offer for open ask. I organized this functionality through dynamic cards, which reflect all the necessary information about the open ask and contain a form for sending an offer.
From the point of view of logic, everything works perfectly. However, the problem is strong page brakes, the reason for which is not known.
I looked at everything that could cause a loss of speed, but found nothing. There is one relatively large query on the page, but it is optimized and loads quickly. The possible reason could be the lack of unique identifiers for dynamic elements, but I added a dynamic id to all such elements.
The drawdown in speed looks as if some incredible calculations are made at the DOM level when entering information in the form begins. And there is a very clear pattern: the more open asks are reflected on the page, the more active the speed loss begins to appear. Below I will give an example with only 13 open asks, if you open the ask and start entering any text in the form inputs, you will feel that the page starts to slow down. I’m afraid to imagine what might start in combat mode after the release, when there may be several hundred open asks…
Is there a specific actions that needs to be done to slow down the page?
As I checked it and everything seems to be working fast and I can’t see any delays …
No, it's definitely not because of this request. It is used in many other places and there are no problems with it. Multiple tests show that its loading time is within 250 - 380 ms:
It is not the loading time that is the problem, but the data manipulation on the very large dataset that is causing the issues. I see that selectstantion has 12364 records. This is used in a repeater that repeats 52 times. Data is getting cloned for each autocomplete where the large dataset is used. That is a total of 642927 records.
I checked the performance and see that an update of the autocomplete takes about 100ms, it seems to do this each time you expand/collapse something on the page (don't know why it actually needs an update then). It does this for each autocomplete on the page (also the invisible ones), that is 52 times 100ms. So about 5 seconds.
I thought about it. But for some reason I missed it. Well, the problem is clear. How can I get around it?
AutoFill is used inside the form, which in turn is located in the repeater. From the point of view of the interface, this is the most convenient solution for the specific business logic of users of this application.
What can be done to make it work well and stable technically?
This file creates errors in the autocomplete component. I managed to make only this screen, because due to the cascading growth of errors, I had to urgently stop the task and close the page:
There are no errors. In terms of speed, it got a little better. However, the combination of autocomplete and repeater still creates a large load and it is very difficult to work with the page.
Could you try putting the content of the collapse in a conditional region that only gets rendered when expanded. That should prevent all those autocomplete updates on elements that are not visible.
I agree that the increase in productivity was significant. However, combining autocomplete with a repeater still creates a very large load, which makes it impossible to use the page properly. Therefore, it seemed to me that the optimization did not give a significant increase, although in fact it was. I hope that in the future these two components will be better combined with each other, and it will be possible to use them without losing performance. I had plans to use them together in other projects.
Yes, that's what I started doing yesterday, as soon as I found out the exact cause of the brakes, thanks to you @patrick. Thank you very much for that! I had to redo the design and put the form in a modal window that opens with a button (instead of collapsing). This helped solve the speed problem, since autocomplete is no longer repeated. But users like this design less. In which, I partially agree with them. It was very convenient to give an offer without any modal Windows, directly without looking up from the order. But it is obvious that it is better to make the interface work fast and stable first, and then as convenient as possible. Than when it is convenient, but does not work.
I don’t know if it would possible to add options to the autocomplete feature, but if the equivalent of a debounce option or a way to specify matching to start only after a specified number of characters, it would make the feature far more useful for large data sets.
If the first 3 or 4 characters are pasted into the autocomplete input, matching is almost instant - many times faster than typing each character (which returns results which are probably of no use anyway). It might be possible to use a dummy input to populate the autocomplete input after a certain number of characters - but I haven’t been able to get this to work.
I didn’t know there was this component in Wappler, so I didn’t understand Patrick correctly. Thank you Teodor for clarifying, otherwise I would never have found out about this component…
I really hope that this will help solve the problem and keep the interface in its original design. At the moment, I’m a little confused about the correct condition. As a condition, I’m trying to set the collapse opening with a dynamic id, like this: ('collapse_' + productid).collapsed
Hi Tom! Yes, I remember that you already suggested this in another post. And I support this idea. But here we are discussing another problem that is not directly related to the operation of autocomplete itself. Here we are talking about the interaction of autocomplete and repeater. When you have hundreds or thousands of autocomplete on your page.
