Skip to content

Exploring alternative approaches to lists #88

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

Open
seancdavis opened this issue Jan 5, 2022 · 0 comments
Open

Exploring alternative approaches to lists #88

seancdavis opened this issue Jan 5, 2022 · 0 comments
Labels
feature New feature or request pkg/source-files
Milestone

Comments

@seancdavis
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request pkg/source-files
Projects
None yet
Development

No branches or pull requests

2 participants