I’m looking trimming the fat of an application. Yes, there is a lot to do on the ‘normal’ part of the application: removing unused elements, using more reusables, etc.. But I’m tempted by the magic / silver-bullet’ness of the this little button.
It trimmed quite a bit of stuff, almost 10% some 6 MB of JSON.
It can result in a bug where you permanently can’t access data if you delete a field type then optimize without first deleting the data that uses the field type. Other than that it just cleans up junk css/etc.
if you don’t optimize the app often enough, it can get too big and the optimize app button always crashes. There’s no fix in the works for this, even for enterprise customers
Thanks. So I should first identify which fields are unused, delete references to them, delete related data, and only then delete the field via the optimize application?
I also plan to use this thing - but:
Are the changes reversible before I approve anything?
I for sure have some not fixed deleted fields from the past lingering in my app. So in the worst case scenario I will lose access to those old deleted data right? Or I can loose anything that’s currently used?
If I use it on branch 1 can it do any damage to the rest of the app?
From what I see in the network tab, it actually pulls the entire app again – via calls to load_multiple_paths and load_single_path – and then does something on the client side. So I guess it’s just a matter of time before @georgecollier reverse engineers that function and gives us a better version of it.
It runs wholly client side. You know how sometimes issues only appear when you load a page/reusable? This basically loads all of them, and checks each for issues. Hence it can kinda break on large apps and timeout.
Those are basics needed for functionality, especially since it crashes all the time. I also need the ability to view only certain categories and search as well, which can’t be more than an hour of dev.
I always have dozens of unused element properties in the list. I’m not quite sure what that means and why that takes up storage, but when I clean those, I often somehow end up with errors?!
In terms of the gotchas, there are 2 that I’ve noticed:
Unused plugins—despite what it says, they aren’t necessarily unused, and often removing those plugins causes many errors (and annoying ones since the original use of the plugin isn’t viewable, so any conditional etc. has to be added from scratch if you don’t restore).
Unused reusable elements - if you use a reusable element for a stylesheet, then it may not be used anywhere in the app, so it will appear in the cleanup list. In order to avoid accidentally deleting this reusable, I usually put a (non-detached) instance of this reusable on some admin page…
optimize application always crashes - have tried all options on chrome and safari on newest MacOS on M2 Pro chip. Also tested on very fast windows machine and even just deleting one element with the rest de-selected results in a crashed page. yes our app is large. page says ran out of memory, even on 32GB i7 14700K system.
100% it always times out and the page crashes. memory error. sometimes it asks to wait or cancel if it notices a delay, and always promptly click wait. other times it just crashes
Tip 1 : add to your calendar a reminder every (first monday of the month?) To optimize often and not get stuck
Tip2: don t use it if you build reusable innative mobile ditor : My founding is the optimize is linked to the app search tool, and both find mobile reusable are not used anywhere (but they are )
Tip 3: don t optimize on friday, like never deploy on friday and tell the team before optimize because there will be a lot of broken thing, as “deleted fields” becomes issues by magic after optimization (when they were not before)
Issues with tip 2 and 3 have been reported to the suuport
ALWAYS create a save point before you run it. I made the mistake the first time I used it years back and never again. Always create the save point before you optimize.
This is an area where a lot of the issues seen in the issue checker would be. This happens because of a nice feature that Bubble has in the platform, which is the ‘restore’ function for deleted data types and fields. If you have deleted a field or data type and in a dynamic expression somewhere in the app that data type or field is used, it will remain blue (ie: no issue) so that in the event you restore the deleted data type or field, all the dynamic expressions that used them are still working properly.
If somebody runs the optimize application function and then sees lots of issues related to a data type or field, they should restore to save point, use the app search tool to find all uses of the data type and/or field and remove those dynamic expressions, create a new save point and then run the optimize function again.
These can be such a pain in the butt to track down. These are usually things that are ‘hidden’ in the sense that in the editor on an element we might need to click into a sort of option that opens a sub folder of sorts (for example use of calculate function to convert coordinates to addresses). If you had at one point used the thing, added in the values as dynamic expressions to data types or fields that were deleted and so the optimize fully removes them, those expressions in ‘sub folder’ are still there and red, but the thing is, you may not still have enabled the option that has the ‘subfolder’ visible, so it is really difficult to know where to click as the issue checker will not open that ‘subfolder’ and just opens the element. Drives me crazy sometimes.
Nice trick. I’ve always struggled to scroll through the large list to uncheck those types of items.
This is due to the restore function requirements.
One of the reasons I have to use this often enough is to integrate from application A full feature sets into application B where application B had previously attempted the same feature and so there may be some overlap between data type names as well as field names. Since Bubble upon creation of a data type and data field creates an internal ID for those, using the names we provide, and doesn’t update them when we change the ‘labels’ we give to the data type or fields, trying to integrate the features is more tedious as the existing data types or fields in App B have the same IDs as the data types and fields in App A, which means the mapping of all dynamic expressions using those overlapping data types or fields is off.
So for example, when I need to integrate my Blog Builder into a client app who attempted to create their own blog, I usually have to first delete all data types and fields and option sets that share the same names as those in my Blog Builder, and then optimize the application to really remove them, which does actually wipe clean the app and so those old data type IDs are actually gone. So if I copy my data type directly into App B, now it will allow for the mapping of all dynamic expressions on the elements and workflows to be properly mapped when I then copy/paste the actual full feature set. This can save me hours upon hours of having to manually go through and remap all expressions to the proper data type or field.
)
and tell the team before optimize because there will be a lot of broken thing, as “deleted fields” becomes issues by magic after optimization (when they were not before)