Reusable Element Properties have been an absolute game-changer, and I would like to share a RE that I’ve found crazy useful.
The title of this topic is quite a handful, but essentially it means that with a single RE, you will be able to add a table on your app containing any dataType! Not only will you be able to display data, but also trigger page-level workflows that have the clicked-on dataThing available to them!
The RE will also be able to dynamically display as many rows and columns as you ask it to, change what data is being displayed based on custom states, and also change the datatype being displayed on the fly! You can drastically reduce the number of elements on the page by using a single table RE for many datatypes, as well as making the app generally more maintainable, as you only have one table to change/update.
Demo
Forgive the bad UI, I created a test app just to demo the functionality.
High-level summary of how it works
In order for the RE to be datatype agnostic, you obviously cannot reference field values in dynamic expressions inside the RE. Instead, we will be inputting the static text to be displayed into the RE properties. And in order to tie the dataThing back to the static data, we will also provide the unique IDs of the dataThings.
Setting up Reusable Element properties
These are the core properties which are needed to get the RE to work. On top of these, you can have as many design properties as you’d like in order to dynamically change the design/layout/arrangement of the Table. You really can get creative.
Headers - List of Texts
Simple comma separated list of table headers
Formatted Values - Single Text
This is the text that will contain all the static values that will be displayed in the Table. This is generally a result of a search or a list field +:format as text. Inside the format as text you will list out all the fields you want to show, as well as the unique ID of the dataThing, and any optional datasources such as image urls. Each row of the table will be delimited by the outer splitter string (in my case ‘||’) while cells in each row will be delimited by the inner splitter string (in my case ‘~~’) . Be sure to use a delimiter that won’t be present in the values you are feeding into the RE, do not use a comma!. To be safe, I generally add find and replace at the end of each value to find and remove the splitters.
Example ‘Formatted Values’:
Alice ~~ Smith ~~ Alpha ~~ 1234567890123x123456789012345678 || Bob ~~ Smith ~~ Bravo ~~ 1234567890123x123456789012345678 || Charlie …etc
Inner & Outer splitters - You can change the inner&outer splitters, but this is generally not needed.
Type - Text
The name of the datatype being fed to the RE. This is needed so the correct workflows are triggered on click.
RE Design
You will essentially need 3 Repeating Groups:
One for the Header Titles -
Datasource= Headers
One for the Table Rows -
Datasource = RE's Formatted Text:split by Outer Splitter
And a nested RG for the Table Cells
Datasource = Current Cell's Text: split by Inner Splitter: items until #Headers count (this is so the table won’t show the unique ids and optional datasources inputted into the RE, like images, options etc)
This is the RG that will contain a text element that will simply display ‘Current cell’s text’.
Click Event and dataEntry reconciliation
Once a table’s row is clicked, the RE somehow needs to send the underlying dataEntry back to the page-level. To do this we’ll use the uniqueID and the ‘Type’ RE property
You could set up searches for each datatype, however I use the following plugin:
String to thing / things Plugin | Bubble
The plugin lets you define the datatype of the thing and the unique ID, and it returns the Bubble thing.
I think its quicker than running a search, but i have not ran a methodical test. I mainly use it because it allows the table to be sortable because it can also publish a list rather than a single thing, I wont talk about that in this post, but the process is analogous to the single-entry case.
Here is the basic flow to retrieve the dataEntry:
- When the line item is clicked, set a text custom state to the unique ID of the row. Use regex to extract it from the row’s text (RegexPattern=\d{13}x\d{18})
- Set your StringtToThing’s dataTypes but leave the Strings blank, otherwise it will cause issues Using conditionals, set the strings and activate the event triggers for the correct datatypes. If you set Type 1 to be User, make sure that the ‘user’ conditional sets String 1 and Event 1 .
-
Add as many custom states to the Reusable Element as Datatypes you want to use the table with. In my example, I am using Users and Tasks, so i added a ‘selectedUser’ custom state of type User, and a ‘selectedTask’ custom state of type Task.
-
Add the ‘StringToThing value is active’ workflow, which basically triggers everytime its value is changed. Set the custom states created in Step 3 to the String to Thing’s value.
-
And finally, on the page level add a ‘Do when condition is true’ workflow that runs every time. It will check whether the Table’s custom state is not empty. Generally each RE you place on the page will be dealing with a single dataType, so you know which custom state to check on the conditional; if its a user table, you will check whether selectedUser is not empty.
You can then reference the clicked entry by using RE's selectedData.
Adding a new supported dataType
To add a new datatype all you need to do is set the StringToThing’s parameters& activate the corresponding workflow. Then and add a new ‘selectedThing’ custom state on the RE.
Thats it ! 
Configuring pagination
Pagination is not handled by the RE, it will be handled on the page. Simply change the list of dataEntries being fed into ‘Formatted Values’ by using custom states.
Examples of where this might help
This RE will be useful if you are building an app that needs many simple tables displaying different datatypes. If you want to change the design/format of the table you can do so in a single place, and you wont have to build out every single table manually.
Example: You are creating content management/data visualisation dashboards for super-admins who want to have access to their app’s data so they can edit it/delete it. This might be dozens of tables, now handled by 1 RE.
This method is great to tackle multiple dataTypes at once, however if one particular dataType needs a more complex Table that will be displayed in multiple parts of your app, i would recommend checking out @georgecollier 's guide on making a dataType specific RE :
I really cannot overstate how much time these REs can save.
Happy Bubblin
And most importantly it will then work on all Datatypes, no need to rebuild a new table.
