"Restrict field type to" is missing app type

Hey @emmanuel,
I dont know if i’m not understanding something but shouldn’t the “Restrict field type to” have an app type as part of the options.
I’m working on a plugin where my data source Thing has a field which is also a type thing.
Now in my plugin i want to be able to grab a field name (specifically the unique id field) of the secondary field (which is a thing) so i can use it in my .get expression to get the values.
I illustrate this by the diagram below. So one of my fields in the plugin editor is an App Type which i call event_type.
This event_type has a field which is also an app type (resource_type).
The issue is when i want to get this field name and i choose Fields of event_type, the Restrict field type to doesn’t include app type as an option.
What i was expecting was that since i’ve defined an app type called resource_type this should be part of the list of restrictions fields.
Am i missing something or how do i get the field name of the secondary type thing.
Thanks

I had printed to console the field names using
properties.data_source.get(0, 1000)[0].listProperties()
with different datatype but i’m not sure i can rely on the pattern i’m seeing to hard code things in. I realized secondary fields names have the format prefix_custom_suffix. I see that the suffix is always the type of the secondary field but i’m not seeing any pattern with the prefix so far.
And even if there is a pattern i find this approach dangerous since if bubble changes things behind the scenes it will break my plugin.
Thanks

If it has app type, it means the app designer can only pick a field that refers to the same type of thing that the field belongs to, for example …

Thing ‘Fruit’
field ‘Name’ type text
field ‘Related Fruit’ type Fruit

But by the same logic you could also limit to any other type …

field ‘Nutrients’ type Nutrient list

It would make more sense to have this unrestricted?

Have you got a good example use case to demonstrate the need?

Hey @mishav thanks for the reply.

Not exactly. Since i have defined two different app type, event_type and resource_type. If a property is a type Fields of event_type, the restriction list should include resource_type since there is possibility of a field being that type.
This is why i made the following statement in my initial post.

The blue box with app type in my diagram was to be a generic meaning the list should include all other app types.

For a use case assuming i expect my users to specify a source type which is a Course. And a course has a field called room which is of type Room. What i want is to be able to get a name that i can use to access the unique id (secondary key) of a Course’s room. Hope this makes sense

Thanks for explaining further, its an additional level of referencing than is currently available. That’d be a nice enhancement.

Retrieving a field’s name would be a good enhancement too, rather than relying on a hack of undocumented internal structure.

Hey @mishav i’m not sure this is just a “nice enhancement” to have. If one is to build robust plugins this has to be available or else hacking internal structures can lead to plugins breaking in the future if bubble changes back-end data structures.
After doing some experiments i think i see how they name such fields.
But i’m very skeptical relying on it for fear of my plugins breaking if bubble changes things.
Please @emmanuel can you come in here?
Thanks

So i realized that if an app type A has a field called b which is of type B, then generally bubble names this field as:
b_custom_B
Now the reason why i highlighted generally is that i just discovered if you rename the field, for some reason bubble still uses the old name. For example if a user was to rename the field to say, c, while still maintaining the type, you will expect that bubble will now name the field c_custom_B, instead it still maintains the old name b_custom_B.
Does bubble somehow store original names of things and their fields so that even when they’re changed bubble still internally uses the original names?
This is the very reason why one can’t rely on hacking undocumented internal structures.
I will really appreciate @emmanuel explaining this to me cos it’s driving me crazy. My plugin was working then for the past two days it stopped working and i just discovered its because of this issue.

1 Like

Hello,

What would be helpful here is a clear question, it’s hard to help with many posts.

Thanks @emmanuel for the response.
Please see the top post.
In summary here are my questions:

  1. How do i get the name of a field that is an app type. In the plugin editor the “Restrict field type to” doesn’t list app types as an option.
  2. I’ve noticed that bubble names such fields as fieldname_custom_fieldtype. Is this correct?
  3. I’ve also noticed that when a field is renamed bubble still keeps the old fieldname. Is this also correct?
  4. If question 3 above is true then how do i get the original field name.

Hope these are clear, if they’re not the first post describes them into details with an example.
Thanks

I think you misunderstood was “Restrict field type to” is about. It’s a way to say “i just want the user to be able to pick a field of type number, date, etc.”.

If you pick field of a type, the list will be populated with the list of fields.

My challenge is that the field is of an app type not any of the standard default types like number, text, date, etc.
I have two app types, event_type and resource_type. The event_type has a field which of of type resource_type.
What i want to do is to be able to get the field name of resource_type. The restrict field type doesn’t list app types and it is a mandatory field. Meaning whatever i choose my users won’t be able to pick the app type field.
Please see the diagram below again to see exactly my problem. Thanks

Then we don’t have a way to do this, and I don’t think I see why you need this. The application’s data types are unknown when you build a plugin, what is knows is whether you want a field to return a text, number, date, etc. That’s where you want to be able to refine the type of the field.