Considering the current way (see image in link preview of the current way), is there a way to pull the information from the json node related to the specific information block without having to load all the information from this collection at once? In summary, is there any technique for when I set the information in the frontend of the specific block, I only bring to the browser memory that specific part of information from the collection?
Within my scenario where I have a json return with a lot of information (various nested nodes):
Instead of having 1 endpoint in XANO with just 1 single collection, should I split these data creating an endpoint in XANO for each specific block with its respective collection? Having more collections, I can manually set to keep loading this information into each specific block through a workflow. E.g., When expanding the accordion, I load the collection related ONLY to that specific block. Would this be the most performative way?
I appreciate the help in overcoming this performance challenge.
You could also just make
→ On accordeon click
→ Set loading state (display loader)
→ Workflow Xano Request to get the data for a given accordeon (need a specific endpoint taking an identifier to return the right information)
→ Put the result in a variable
→ Set loading state to false
→ Display the data
It depends of the experience you want, a lot of micro load time for every accordeon or a large load time once and then a smooth experience on accordeon, it depends of how often people want to open these accordeons too
If your JSON contain like hundread of blocks but a page display only ten of them you could also make your endpoint take a query param and use it as a filter so you retrieive only the page related blocks and not the whole collection of blocks
TLDR:
If your page contains too much blocks and you feel like it take too much time to load, you can load the detail one by one when clicking on your accordeon
If your page not contain a lot of block but your collection contains a lot and so make too much time to load then you should filter the collection xano side so you get only the relevant blocks
Thank you very much for the tips, @Alexis , up to this point. Indeed, the way I was handling my data on the screen was literally causing errors in the browser (apparently due to excessive memory usage).
Another question about optimization:
Do you think that adding conditional rendering to the accordions, only rendering the elements of the expanded accordion on the screen, is a recommended performance practice?
I’m thinking of the following logic:
Upon expanding a certain accordion, I display the elements and content using the conditional rendering condition. If I click on another accordion, the content of that other one is rendered on the screen and automatically the first accordion is closed, and its content is no longer rendered.
Does this use of conditional rendering make sense to you, or would this dynamic of conditional rendering cause excessive processing consumption?
The major issue at this moment is that, due to these memory errors in the weweb editor and still being on the Free plan, I don’t know if:
1. Everything is okay in production, there are no issues, and it’s just a problem of too many elements to be viewed in the editor. 2. There is some problem with the optimization of data loading because the issue also appears in production.
It’s very difficult in this scenario to know what’s affecting the application in production and to take the appropriate optimization actions.
Maybe I actually need to pay for the weweb paid plan, even while my application is still under construction, to ensure that the editor’s freezing is a reflection of poor data loading management.
In my view, this would be an area for improvement in the product, allowing for live testing outside the weweb editor, simulating access on a separate URL, without the performance interference from the editor itself.
