Populating Default Options in Modal Based on Table Selection

App Building
,
1

I'm a novice at Retool and my expertise isn't primarily in development. I'd value any insights or advice.

I have four distinct tables (i.e., table_orders1, table_orders2, and so on) in Retool, all drawing data from our internal "orders" database. Each table's data is segregated based on a role field, facilitated by individual dropdowns.

The challenge I'm facing involves modals: Each table has its own button which triggers a modal window. When activated, I aim to populate default options in the modal fields, specifically to fetch the email list associated with the "clicked" table. Although I've created four separate modals, each tailored to its respective table, this setup seems unsustainable. Making alterations to the modal content would necessitate replicating the changes across all four, which is far from ideal.

Is there a more efficient way to achieve this dynamic behavior without manually configuring each modal? I've created a video for a more detailed walkthrough of my current structure:

I'm solved this by making use of a a global variable "currentTable" that stores a copy of "which table was clicked" by running a script that "sets variable" and opens the modal after, from each button "event handler"... but I'm pretty unsure this to be the best route and would really like to learn best practices

image
image1628×835 81.8 KB

Thank you in advance for your tips!

2

Really good idea to have a video explaining the situation (even if it does seem to be a little truncated) it does help when trying to understand the context.

I think it'll come down to how different each of the 4 modals needs to be. My preference here would be to have a single modal with a single form and show/hide fields based on what "mode" it's in - so maybe in your case the "mode" would be which table and button was clicked and what action was being requested.

If they're fairly similar functions (sending an email) then this should be a good option to explore - have fields that aren't visible based on the action.
If they are very different functions then separation would be a more appropriate option.

Your thinking is correct though, your spidey-senses have spotted that each table change is going to need more maintenance work from yourself and creating a reusable, modular approach, is always going to make that easier.

I realise that's not a very straightforward answer ("it depends") but understanding your use case will determine what the "best practice" is here

3 Likes
3