Prioritizing DRY (don’t repeat yourself) etc. and modularity at the expense of everything else can hurt you in the long run. This also goes with custom events, reusables, etc. Yes they have a place, but at a certain point your app will be so wrapped up in layers of conditions and abstractions that it will actually slow you down. Sometimes it’s better to repeat yourself a few times (not 100 times) rather than overindexing on the “perfect optimal” way.
After watching the video I’m having a hard time translating it into solid advice and actionable steps to take within a bubble app. At the heart of it, it seems like it says, “don’t get bogged down in a future that might not happen and just build something today to get it out there so long as it is functional it doesn’t need to be optimized, and then only after gaining some traction and realizing the build is poor, go back and rebuild with a focus on optimizing”.
Yeah, that’s the central thesis.
draft code → working code → refactored code.
Balance between depending on time and allowance you have in ur company.
The goal is to not lose ur customers
Only big companies can afford refactored and scalable code right from the beginning.
Bad practice to extrapolate traditional coders problems to no coders. They are 10x slow
Or to gain new ones, yeah.
Even then, they don’t really do that.
The video just stresses the importance of modularizing code in the right way.
But it still applies that modularization is needed for proper maintainability of codebases.
Well, plenty of companies build in tech debt and bugs so they can get that MRR after it’s built.
Just to argue a little against myself, recently I used a custom event with 2 parameters to control toggling items into a list. Normally you’d have to include 2 separate workflows for each toggle due to the race condition of sequential actions adding/subtracting into the list, but you can simply use a (yes/no) parameter that indicates whether the item should be added or subtracted. This is an example where custom events literally save you time WHILE you’re building, in addition to being more maintainable. Not sure if @MattN covers this in his newest 2025 course, but I remember a highlight of his “crash course” vid being a demonstration of why you need separate 2 workflows for competing conditions. Custom events really help with situations like that.
Nice @randomanon that is the type of little tricks that can really allow somebody to build modularly and not have to repeat themselves. In my plugin I’m finding little ways to incorporate these strategies I use into the plugin itself. They really allow you to build one thing that can control all of your data processing needs.
They are great. Below is video example of the workflows for a test app, on the page in which the user takes the test.
One area that I am already planning on updating is an ability to have my local storage not just write on a single action, but to write and then read from the same action via an optional yes/no field on the action.
For custom state setting…you can no have a single trigger event with two actions where the actions have conditions on them as to whether or not to set the custom state value from yes to no as they will compete with each other in the workflow and custom state will not be set properly. Other than that, there are times when you have different numbers necessary.
In the video above there are two trigger events with same condition except one looks at the number as 0 and the other as greater than zero…it is just sometimes more maintainable to see those conditions on the trigger event rather than needing to click into the workflows to see the single action with the one condition (but of course that is just a developers preference).
