Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Support for dynamic elements #1425

Open
bowdi opened this issue Feb 5, 2025 · 0 comments
Open

Feature request: Support for dynamic elements #1425

bowdi opened this issue Feb 5, 2025 · 0 comments

Comments

@bowdi
Copy link

bowdi commented Feb 5, 2025

Context

Firstly, I love the work you're doing and how adaptable this product is!

I acknowledge this is quite a broad ask and probably has many features that can be delivered to better handle this request, but thought we could start with a single issue. As some context, I initially wrote this request as a direct request for a polymorphic reference type but thought i'd step back and describe the problem i'm trying to solve. I did look for related requests but couldn't find an actual feature request put in.

Describe the problem to be solved

I have a few tables that are somewhat polymorphic, and depending on the type of record / row, different columns / scenarios are relevant. Here are some examples to show you what I mean:

Example 1:

A CRM style document that has tables such as:

  • customers
  • orders
  • support requests
  • notes

The notes table can be related to a customer, order, or a support request, but a single row will only ever be related to one. At the moment, if we wanted to create a new note from a list of notes, we'd have to show every reference column.

Example 2:

A inventory / ERP style document that has tables such as:

  • inventory (think an asset but with a quantity e.g. 5x potatoes)
  • assets (a concrete, single item)
  • schedules (e.g. maintenance, end of life)

In this example, inventory and assets could probably be represented by a single polymorphic table, as the only difference between them is quantity, however, there is no way for us to not show this column when inventory is the asset type.

Alternatively, and as shown, we can have separate tables but this means we have the same problem as example 1, where a schedule can relate to either inventory or an asset but we lack a good way of showing this in the UI.

Example 3:

Not a direct use case I have, but have seen in the wild on other platforms.

A Sales focused CRM document that has tables such as:

  • leads
  • opportunitys
  • orders

As a lead / opportunity progresses through it's lifecycle, different columns may be relevant.

Describe the solution you would like

I can think of two features that could help all of my examples:

Dynamic pages via conditional widgets

Ideally, we could set widgets to appear / disappear conditionally, however, I can imagine this would make editing the layout challenging unless there was some way to manage page variants and switch between the different variants / conditional outcomes. I think a more realistic option would be to change the visibility of specific columns of a widget based on some criteria.

I think each widget type would be able to be more or less dynamic based on it's own constraints, for example a related table widget would be able to change the columns based only the selected row as it has to be consistent across every item. On the card list widget you could change the columns based on the selected row or the (related) row itself as the columns do not have to remain constant against each item.

Polymorphic references

If we could create a reference column that could reference more than one table, for example, a single column on notes could reference all things it can be related to.

This has some implications for formulas trying to use the reference I imagine and I can think of some possible solutions:

  • only allow formulas to reference columns that are common across all of the tables (not ideal)
  • provide a function to select a particular column depending on the table is referenced e.g. select_poly_column($related_to, "customers", "name", "orders", "number", "support_requests", "case_id)" would return namefor a customer,numberfor a order andcase_id` for a support request

I am sure there are solutions available today that involve multiple pages with single type tables, formulas and action buttons and such but I don't think they are fit for every use case and certainly they lead to harder DX and / or UX. Although, i'd still like to hear how people handle these type of scenarios today! But I do believe these features, if implemented, could open up a lot of possibilities for users without having to reach for custom widgets / code / workarounds.

@bowdi bowdi changed the title Support for dynamic pages Feature request: Support for dynamic pages Feb 5, 2025
@bowdi bowdi changed the title Feature request: Support for dynamic pages Feature request: Support for dynamic elements Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant