Weeeellll, yes and no. If you’re building a plugin SPECIFIC to your app (there are good reasons for doing this), you might do that.
But if you’re building a general use plugin, you don’t know, in advance, what properties the User object might have and your plugin should not usually care about them.
Inputs to the plugin are presented via fields in the plugin interface, which are then presented to the plugin’s internals as properties of the (unsurprisingly named) properties object.
In general, we access those fields just once (on instantiation of the plugin) and move things over to the instance object (as properties of instance.data)… because all of your other action functions get instance sent to them.
So for example, while there are things we can do in function initialize (which is called just once) — like set up some aspects of the canvas (if our plugin is an element with visual features) — we get the main properties object only in function update (which gets called AFTER function initialize).
So anyway, the thing you’re looking at (which is something sourced from an API Connector call, obviously), is not accessed via the User property of context. Instead, the plugin has an interface field of some type — where the Bubble developer user will present to us a value (which might be User’s some-whatever-we-don’t-know-or-care-What-it-is).
But the plugin will now see that as properties.some-thing-we-Do-know.
So, for example: Let us say we have a field where the Bubble dev will send us info about “number of cats”.
In the plugin builder, we will define a field captioned “Number of Cats”, which will become properties.number_of_cats to function update. (Let’s also assume this field is optional.)
There (in function update), we will do something like:
properties.number_of_cats ? instance.data.number_of_cats = properties.number_of_cats : (instance.data.catHater = true, instance.data.number_of_cats = null)
Now, the Bubble dev might send number of cats as a scalar (5), as an expression (User’s CatList:count), or as the result of a search (Do a Search for… Cats [constraint Created By Current User]), or as the result of an API call (Get Data from API… CatSearch… parameters blah blah blah)… and we don’t care.
To us, and to the plugin, all of these just yield us a number we can use in our plugin’s internals — properties.number_of_cats.
(Lists — arrays — require special handling using the list API explained in the documentation for properties.)
So that’s how you generalize stuff. If you’re building a plugin specific to some single app, you might do what you’re suggesting, but in that case why build a plugin? (Just do what you need to do in Bubble.)