Skip to content

[Feature Request] More powerful Object Variable Type widgets #501

@m4rrc0

Description

@m4rrc0

Hey. It's probably for v2 or later but I want to share my thought while the idea is clear in my head.

So... object variable types is an awesome idea! It is incredibly handy for conditional fields.

I think two key improvements could make it even more useful.

1. Don't force types to be objects

Currently, types need to be objects. It makes sense for Variable Types List (arguably) because then we can inject the typeKey.

I would still argue it could be the developer's responsibility to avoid ambiguity and sometimes having different data types might be enough. We might not need the typeKey and prefer using another widget than Object as children of a variable type. But I understand the choices that have been made for lists to avoid ambiguity.

For Object Variable Types widgets on the other hand, the names of the types are already the object keys so there is no ambiguity. It would be a lot more flexible to allow types to use any widget.

2. allow_multiple or allow_multiple_types

We could allow adding multiple types (=object keys). Obviously, we could only add one of each type because the type name becomes the object key so we can only have different keys. But we could then get an object with multiple keys. Each key would hold one of the defined types.

Combining the two features would open a cool UX improvement for optional fields in my opinion. Here is an example with image attributes:

...
{
  name: "imageAttributes",
  label: "Image Attributes",
  widget: "object",
  allow_multiple: true,
  types: [
    {
      name: "alt",
      label: "Alt Text",
      widget: "string",
    },
    {
      name: "title",
      label: "Title",
      widget: "string",
    },
    {
      name: "width",
      label: "Width",
      widget: "number",
      value_type: "int",
    },
    ...
  ],
},
...

In the UI, we could then click Add Image Attributes and select the attributes we want to fill in and not get cluttered with the ones we don't want.

I think a UX like this is a game changer when having a lot of optional fields.

2 Bonus: Mixing fields and types would be awesome.

Following on the example above, if we could use fields and types at the same time it means we could do:

...
{
  name: "image",
  label: "Image",
  widget: "object",
  fields: [
    {
      name: "src",
      label: "Image",
      widget: "image",
    },
  ],
  allow_multiple_types: true,
  types: [
    ...
  ],
},
...

So, some 'always visible' fields, then the option to add 'hidden fields' when necessary without cluttering the UI when it is not.

And on the dev side this translates very efficiently in actual Objects, html element, component, ... without needing to transform the data.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions