I mentioned this briefly in another post, but have now confirmed that building a directory menu of file trees (i.e. layers of nested repeating groups) natively inside of Bubble produces an incredibly slow experience for the end user. Things are a bit faster on the desktop (6 seconds for two trees of 9), but it can take 15+ seconds to load on mobile when two trees of 9 layers are expanded…unfortunately, this is unusable for a production application unless the the app is named “Churn”.
I tried loading RG data both via a query (do a search for…) and via a linked list attached to the user (User’s list of folders) - the results were the same. I then stripped all the conditionals on each layer…minimal effect on load time. The page loading speed depends on the device accessing the application (desktop vs. mobile) and the number of sub-levels being loaded. Loading layer 7-9 is exponentially slower than loading layers 1-2 . Layer 5 through layer 9, on any given tree, will slooowllly expand downwards as if you recorded a video of a typical React-based directory menu in slow motion:
Currently open to ideas. If there are any full stack developers that stumble on this post, I’ll consider ‘yes code’ plugin ideas too. The nested directory menu is a core feature of this application.
I usually don’t go further than one layer, so a folder and a sub folder is all I do, mostly because of complexity issues.
When I do set that up though, I have a single data type called folder and a data field called ‘parent folder’. If the parent folder is empty, it is a main folder, if the parent folder is not empty it is a sub folder of the parent folder.
In that my nested repeating groups avoid a search (always avoid searches in any element placed inside a repeating group as the search would be performed once for each cell in the repeating group and slows down the app).
I have a list shifter element (this could be a custom state as list as well) to hold onto the list of folders that I find via a search.
I have main repeating group reference the list of folders and filter folders with constraint parent folder is empty. Then the nested repeating group is again referencing the list in the list shifter (or custom state) and filter with constraint is parent folder = current cells folder.
You can do this for as many nested repeating group layers as you want, just my personal preference not to go beyond 1 layer, but the setup should work just fine for as many layers as you want.
Use only one repeating group that you populate with a depth first sort of the tree. Indent according to depth. For the tree store it flat with each row referencing a unique parent row. You can make your life easier by having a depth sort field that stores a number strictly between 0 and 1 that represents the depth first sort (because numerically sorting numbers between 0 and 1 is equivalent to the lexicographic sort on the digit expansion of the number).
Interesting. I just adjusted the height of the repeating groups to 50px, but it did not resolve the performance issues. I wonder if this is a contributing factor in addition to something else.
UPDATE - adjusted height of row, RG, and all containers for each nested layer. No improvement so far.
@aaronsheldon - you are officially Babe Ruth of the Bubble forums. You knocked this one out of the park! Excellent advice.
I deleted all of the nested RGs but two and created conditionals to adjust the left margin of the 2nd RG based on the numerical value of each folder’s depth index…1000% performance increase. I then ran into the issue of separating branches into mutually exclusive subtrees (ex. level 3a has a subtree, level 3b has its own subtree, level 7b and 7e each have subtrees, etc.), so I created a pathname/url field for each folder and then sorted the second repeating group by that field…problem solved. I may not be doing things in the most efficient way with 9 conditionals statements for 9 levels based on a depth index range, but we are now back into production-worthy territory!
How would you approach the use case of ‘moving’ a tree into the branch of another tree? (i.e. users ‘moving’ folders and their associated children between various branches/trees) Now that the directory menu relies on precise numerical values of a depth index, the parent folder and all of it’s children will need to have their depth index recursively updated based on the insertion point on the new hierarchy that they are being moved into (or the child folders will not indent properly due to the offset depth index values from their original tree’s hierarchy). As far as I’m aware, Bubble does not allow us to explicitly specify synchronous workflows (update a child’s depth index based on parent’s depth index, etc.) and I don’t believe we can implement loops or recursion inside of Bubble for this type of situation yet.
Exactly! Careful recursive depth changing is what you will need. The math is going to be a bit tricky but it can be done. This is exactly analogous to the difficulty in updating binary trees to maintain balance. It is unfortunate that Bubble does not have any intrinsic depth first sorting.
