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

Add Union Field Type #250

Open
Saeris opened this issue Jun 15, 2022 · 3 comments
Open

Add Union Field Type #250

Saeris opened this issue Jun 15, 2022 · 3 comments

Comments

@Saeris
Copy link

Saeris commented Jun 15, 2022

Basically, allow me to define a union of types that a field can be.

Simple example would be string | string[]. Config proposal:

  // ...
  author: {
    type: `union`,
    of: [
      {
        type: `string`
      },
      {
        type: `list`,
        of: {
          type: `string` 
        }
      }
    ]
  },

This would permit the following frontmatter:

author: Foo Bar
# or
author:
  - Foo Bar
  - Baz Qux

If this is already possible with the existing field types, please add examples to the documentation which demonstrate how to do this, as it's not readily apparent how this can be done.

@seancdavis
Copy link
Collaborator

Interesting case, @Saeris. I could see how that would make the editing process easily account for multiple authors without needing to remember different field names.

The easiest way to get around that today is to use an array for author. Although it seems annoying, I think you might actually find that it cleans your code up. If author is expected as string[] you'd have to do less type-checking in your code.

And with YAML frontmatter, you can still do this in one line when writing content.

author: [Foo Bar]
# or
author:
  - Foo Bar
  - Baz Qux

Another (future) option is to use separate fields for the string and string[] fields (anotherName and authorNames as an example), and then use a computed field to combine them. The problem is that the type definition likely won't be created properly right now. (That's a guess based on #241.)

@schickling
Copy link
Collaborator

Generally I like this idea but I think we'd need to think through the potential edge cases thoroughly before implementing a feature like this.

Usually union types use some for of tagging (e.g. see this article) to properly infer the used type. We'd need to make sure we can always infer the used type unambiguously at runtime.

It's also not entirely clear to me whether your use case for unions is meant as "shortcut syntax" and you'd always want to coerce the data into becoming e.g. string[] after all or whether you want to maintain the data on a document level to stay string | string[].

@stale
Copy link

stale bot commented Sep 3, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants