Hello,
When building a plugin’s visual element, you define its fields. All of them are displayed by default in the bubble editor when you use this element.
Is there a way to make some of them appear conditionnally, i.e depending on the value of another field, just like the built in checkbox “define each border independently”
that unfold the additionnal fields only when checked:
Thanks,
JP
No, I don’t believe so, unfortunately. Some of Bubble’s own built-in plug-ins do that kind of thing, but such “conditional display” functionality is not exposed to plug-in developers. 
Thanks, i guess it has to be expected… 
Indeed, such a feature is not available in the plugin editor. It would be super-nice, though.
Hmm… Actually the “Excel-like HandSonTable” plugin does even more… It displays checkboxes properties allowing to hide columns based on the datatype you chose to display… So not only being able to show/hide a list of static properties, but even to create dynamic ones… Unfortunately no docs/sources
This is seriously and sorely needed @rohan.sehgal. Can you share any work around or timeline for exposing these capabilities to plugin developers?
Would be so great to have dynamic input fields (the only place this appears at all is in element actions where you can have key/value pair fields which are dynamic to the user). Obviously, that’s not enough. It’s so annoying that I have to make decisions about “how many things should I let the user select here?”… Like, in Floppy the interface to Floppy Reader is just completely static. “Hey, you can select up to 6 scalar and 6 list data types.” But that’s so dumb because really the user should be able to set up as many or as few as needed (and my code is completely dynamic already). Grumble.
Additionally, it would be great to be able to just copy a set of fields (whether they are the fields for a main interface or for some action) and just paste them somewhere new. LITERALLY the hardest part of making sophisticated and useful plugins is that every damn action’s interface needs to be built from scratch.
(For example: I have a bunch of actions in the Floppy element that I’d like to turn into SSAs, but I don’t do it because rebuilding the same damn interface I already built takes me a lot of time and literally gives me carpal tunnel. Setting up fields takes much more time than the code in many cases.)
Epically annoying. And I second your point about being able to copy sets of arguments for each action or element. It is possible to right click copy an element or action and paste it to create a duplicate but it’s not possible to copy just the fields that end users see… as you said.
Man, I just tried syncing a plugin I’m developing to GitHub so I could start coding in a proper editor with syntax highlighting/linting. Can you believe that if I add nothing more than a blank line in my local git copy, push that change to GitHub, and finally sync that change to my plugin, then it completely ruins the plugin!? For some reason the updates look fine in the plugin editor but the moment I go to test the plugin in a demo app, nothing works. The entire page that uses the plugin goes blank!
So sad. Like, help us make plugins Bubble. Help
@zelus_pudding, I write all my code in a self-executing function that I paste into Code Instance (for an example, go look at my open source “Fielder” plugin).
Then all the other code boxes are just calls to functions that hang off of instance.data. And of course I don’t initialize states using the state initialization boxes as that’s just silly.
So 99% of my plugin code is in a single file and of course I edit that in VS Code. Everything else is just a little stub.
As for the problem you just experienced, if you have a linter that’s automatically fixing stuff (or you’re fixing stuff your linter is identifying as an issue), note that the first line of everything in the Bubble plugin code boxes is not proper JavaScript (e.g., function(instance, context) {– this is not a proper JS function definition, it’s just how Bubble detects where the code starts. This is moronic, but there you go. [Also see my note at end!]
If you don’t have the exact (again, not real JavaScript) string Bubble expects there, Bubble will balk at it. (And yes, this makes it hard to self-minify certain types of code - particularly in SSA’s - if that’s a thing that one needs to do.)
One thing to check: If you try to “Submit a new version”, the plugin editor may give you a clue about what it thinks is wrong with your plugin (there’s some checks it does there).
END NOTE: Also, while writing this, I did just go and mess with changing that first line. Something has changed in the plugin editor… if the first line was not exactly what Bubble expects, the code box would complain something like “this code cannot be interpreted as JavaScript”. But it seems it is not doing that right now.
(I appreciate that Bubble does seem to be actively working on the plugin editor and associated stuff, but the only reason we know this is that they are regularly breaking things in the plugin ecosystem. Most recently, they did something that made Bubble not see Events from plugins, and a few days prior to that made a silent change to the SSA API that made certain object properties “disappear” (become not inspectable via Object.hasOwnProperties()) which of course broke a good bit of code for a while.)
Super appreciate that thorough write up Keith (and sorry I haven’t followed up sooner - have been working on a brand new plugin I’m launching this week and have done a poor job replying 
)!
Very interesting/useful to hear about your workflow. I ended up adopting several aspects of it 
My issue was that when I synced from my local editor back to github back to the Bubble plugin editor… just after adding a new line in the middle of my code (everything else stayed the same) the sync corrupted my plugin editor to the effect all the code was missing from my update function and I had to revert to the prior version of the plugin. I dunno if that was just a one off bug but I decided to never try that again and just adopt a “copy from VS Code then paste to the plugin editor” workflow.
Eventually I think I’ll start minifying my code as well (especially given your recent post about how the Bubble no longer does this automatically) but I got to make sure the release is a little more stable before I get there.
