Skip to content

Exploring alternative approaches to lists #88

Description

@seancdavis

The way lists work have been tripping me up in writing the documentation. I'm documenting how they behave today, but they feel a little too magical. For example, there is different behavior based on the type of the of option.

Perhaps any field could be a list. I could do something like this:

{
  fields: {
    // ...
    tags: { type: 'reference', of: Tag, list: true }
  }
}

If we were to do that, it would also be interesting to consider if any field could then be polymorphic. For example, what if I wanted a list of strings or numbers?

{
  fields: {
    // ...
    someListField: { type: ['string', 'number'], list: true }
  }
}

This polymorphic field type could be interesting to consider outside this context, too. Perhaps any field (not just a list) could be one of multiple types and still be valid.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions