As George mentioned, this is a tool in an arsenal - not necessarily the best way to go about things in all situations. I only really use it for view-only tables with a simple click-event to open a popup/navigate to a different page.
No - the Agnostic Table RE can handle any datatype, but it should only display a single datype at once.
You might be able to get it to display multiple Datatypes at once, but it will require some workaround, as you won’t be able to use the :format as text operator. Likely not worth it.
Advantages:
Dev speed- Once you get a hang of it, it’s much quicker than cloning a RE and changing all references/conditionals/workflows
Maintainability and consistency - If you want to change the style/ui of your read-only tables, you only need to do it ONCE in a single RE rather than going around looking for all the places you’ve cloned RG tables.
Cross app - quickly copy it to other apps without any dependency issues except applying a few styles
Disadvantages
Needs pagination: This is important - do not display lots of data at once. You are giving up Bubble’s native lazy loading and all data is funnelled through the :format as text operator before being displayed. I would recommend keeping it between 30-50.
Yeah, the JSON-esque formatting isn’t exactly industry-standard, but hey, it works and it’s all contained in the :format as text. Having two monitors helps so you can compare the headers when building the Formatted Values
If you need more advanced features (icons, tags, dropdown actions) things can become cumbersome. I’ve gotten everything to work, but likely wouldn’t recommend it here on the forum. Some features (eg nested tables, expandable tables) are just deal-breakers.
@nico.dicagno Yes your approach is great when the circumstances call for it as is @georgecollier ‘s when necessary.
George’s reusable approach works really well for internal tools where users can choose which columns they want to see. I’ve made on small adjustment that is very helpful: I use one list of option sets for which fields to display instead of a bunch of yes/no for the columns which lets the same reusable work across different datasets without changing the parameters. I just repurpose the sort option set so it’s all intertwined whether to show a column and the ability to sort by it. It also makes the headers easier to show/hide based on whether or not the list of columns includes this groups field (same for sorting)
I don’t think this is the way to do tables. It’s one good option depending on the use case.
What I’m really interested in, and would love to hear more about, is what other modular approaches people are using, besides the 2 mnreitoned here to more easily and quickly build out tables?
Stepping back, this also feels like the clearest example of where Bubble’s move toward AI should start. Tables, filters, and sorting are low-hanging fruit with massive impact, and they’re where we all burn an absurd amount of time. AIs can easily build the tables using the dataset and field and basic styling in the app and it’s a bit ridiculous that in 2026 thousands (tens of thousands?) of hours will be spent on such busy work…
To be honest here, based on my own experiences with this dating back to early 2022 and honest self reflection, there really is no circumstance necessary, other than potentially wanting to use a switch to toggle between data types but even then, we can just hide and show different tables and ultimately be more efficient in our workflows when building and have an easier to maintain and expand application.
Most tables in an app, would not be read only, and most of the time, if a table is needed to be read, it would also likely need CRUD operations anyway.
You can, it is simply just using a merge on two different :format as text operators, this is how I set it up in early 2022 to take both Google Calendar events and Microsoft Calendar events into one repeating group.
I would find myself disagreeing with this statement based on my own experiences, other developers may themselves find it faster to have to trudge through all the different formatting requirements and custom states etc. but for me personally, just changing dynamic expressions to point to correct data fields when switching a data type is super easy, especially with proper naming conventions, a lot of times Bubble does that for you anyway (ie: if two data types both have a field of ‘name’ then bubble remaps it properly when switching data types)
This is why bubble has Styles built into the platform and why developers should make use of them…one area to change everything that uses those styles, we change the text, colors etc. in styles and if your RG is not using styles in the content of cells, you are causing slight performance issues as that would cause bubble to add the UI to each cell, rather than calling the style once.
True, the styles and any custom states
This is where my honest self reflection and help from other developers lending a helping advice to me on understanding and using JSON more helped me avoid this approach.
Yes, one other very important drawback is no sorting
This also works well, so that the group in the rg has a value of ‘option’ and conditional when ‘this group option is not in hidden column list’ to make it visible…makes it super quick to just copy that group and paste and switch the option/field of that group - can even put text in group to groups options display and set up most of the headers quickly, same for values in the display of data…this also enables features like highlight a certain column.
Overall it is not, and there are no real use cases for it that; at least that is what I’ve found in reflecting and tweaking on the concept for past 4 years.
Using a Hybrid Data Structure approach. Can create an API data type that is the ‘one data type’ and set json keys to generic values. This allows for you to more easily feed multiple data types into one RG and format as text, but benefit is you are using this API object as the data type of the RG which allows you to much more quickly and easily set up and keep functions like sorting and filtering possible. Also just makes maintenance and expansion much easier as you do not need to constantly add more custom states or trying to keep track of which field is what item #.
I’ve never really used the approach to have one reusable for all tables, but more inline with my view of best use for this type of approach using text and fake json or a hybrid data structure with api object of feeding multiple data types into one repeating group at the same time, but I’ve been toying with a plugin that parses data types as JSON, so can just say in the plugin a datasource which gives an exposed state of the JSON, so that I can more easily and quickly add a cloned reusable for a new/different data type and not really bother with much formatted as text. Additionally exposed state of all fields, so no need for an option set that is list of fields so to provide the hide/show column or highlight column and just use the exposed state as the list of fields to set up hide/show and highlight columns as well as dynamic sortation…
I still do not think I will really focus on that for sometime as it really doesn’t save much time if I just make one solid reusable and then clone and change data types.
Yeah, I’ve personally disagreed with most of the implementation approaches Bubble has had for AI from beginning…I just find it laughable that the first real focus was design, only to end up buying a plugin that fixed the import from figma feature.
