Using the new properties from Reusable Elements: Tips?

So I want to jump in and test out using the new properties from the reusable elements, but I want to make sure I understand the best use case of it.

For example, I have an admin dashboard that has a bunch of tabs to edit settings and properties of a website (tags, pages, posts, courses, etc.). Each tab in turn has a repeating list of those data types. I am going to add an icon button to each repeating cell to delete that data (a soft delete, editing a yes/no “deleted” field on that data type) which will show a pop up to confirm the deletion.

My initial thought is to make a reusable popup, confirm-popup, where I can set properties for the title, and message. The issue now is that the data type of the reusable is set internally, so I have to create another property (one for each data type) that would hold the data type of the cell of the RG I’m working on, for example, tags.

But I can’t set that property through a workflow, so I have to set either a hidden group somewhere to pass that data type to that the RUE can reference for that property, or add a parameter in my URL to pass that through so it can be read. Then in the RUE workflow, I would have to make conditionals for each data type (if property.tags is not empty, make changes to tag for example), so that the appropriate actions take place depending on the instance being run.

Then I would make all the different instances, each setting the appropriate property when the user clicks the delete icon. Is this the correct logic for this process? Because it doesn’t seem to be all that different than using custom states in this case (as the data I’m working with doesn’t need to be dynamically updated), at least to my understanding. I’m sure I’m missing a key advantage of this, which is why I’m asking. :slight_smile:

Tyler does not think the Properties feature will help you here in this specific use-case :rofl: :rofl:

1 Like

Ok, that was my thinking too, but I wanted to be sure. Thanks for the sanity check. :slight_smile:

Probably the big reason I like the new feature is I give a Property a datasource (just like a RE’s regular Datasource), and I kind of set and forget, whatever happens to that data, whatever value changes will just pass through without worrying bout it.

One of my REs is a file browser with file uploader, some misc. tools to merge PDFs, file viewer, drawing/whiteboard section.

But depending on where that RE existed in my app I needed to turn on and off those specific features.

So in this case I have like a TON of yes/no properties. drawingEnabled, uploadsEnabled, fileRenameEnabled, fileDeleteEnabled, pdfMergeEnabled, etc.

Some of those maybe be directly pointed to some condition like “Current user’s Roles contains File Delete” other may be tied to the “Current Page’s Invoice Date + 14 Days < Current Date/time” Some may be a combination of expressions.

Then some addition Properties are “additionalFiles” (list of Files) “additionalFolders” (list of Folders". And the RGs inside the RE are for Files and Folders, I can “inject” some additional relevant files and folder in front of the RGs normal data sources if they are relevant to the Current page’s thing and need to be shown first before the user generated files.

Previously I had to use custom states to do this, but I couldn’t just set everything on page load because it was an SPA, so I needed like a ton of “When condition is true” events checking if like the User role changed where he no longer had access, etc.

But the worst part was if the RE was in a RG cell it got infinitely harder because you couldn’t even find the RE in the options as one of the elements to pick…

1 Like

Yeah, that seems like a great use case and makes more sense.

In my above case, I’m using a single RUE with custom states for each data type I need to edit, with an additional state for “type”. On the RUE I can use the type to change the display title and message, and make conditional on the workflow as well.

So when they click the delete icon, it sets the state of the data type and the “type”. Seems like easiest and least amount of work :man_shrugging::joy:

1 Like