Tinacms: Add the option to add true/false labels for the toggle plugin.

[canrozanes]

Summary

Currently there is no way to add true/false labels to the toggle plugin.
I'd like to request a feature to allow developers to optionally add customizable true/false label to the plugin.

Modified Interface

interface ToggleConfig extends FieldConfig {
  component: 'Toggle'
  name: string
  label?: string
  description?: string,
  trueLabel:? string,
  falseLabel?: string
}

Alternatively:

interface ToggleConfig extends FieldConfig {
  component: 'Toggle'
  name: string
  label?: string
  description?: string,
  toggleLabels?: {
    true?: string,
    false?: string
  }
}

Basic example

const formOptions = {
  label: "Paragraph",
  fields: [{ 
     name: "isBold", 
     label: "Should font be bold?", 
     component: "toggle",
     trueLabel: "Yes",
     falseLabel: "No",
    }]
};

Results in:

Motivation

Sometimes toggle's overarching label might not be enough to capture the toggles intended behaviour. Adding true/false labels for each option would help clarify the intended behaviour for content editors. This would also be an accessibility win.

I was inspired by Contentful's API as it allows for this kind of customization in its contentful-migration package with the following form:

  const blogPost = migration.editContentType('blogPost');
  blogPost.changeFieldControl('hasPublishDate', 'builtin', 'boolean', { 
    trueLabel: 'Has visible publish date ',
    falseLabel: 'Does not have visible publish date'
  });

[canrozanes]

If it's an approved feature request, I'd like to work on it. Seems like a relatively simple change.

[kendallstrautman]

This looks great! Let us know if you need help 👏

I think I'd prefer the alternative API, where the labels are contained in an object. This way, the interface could be something like:

  toggleLabels?: boolean | {
    true: string,
    false: string
  }

And we could provide defaults as 'yes' / 'no'. I wouldn't want to account for cases where only one label is passed if they are both optional.

[dwalkr]

I agree w/ @kendallstrautman regarding the proposed API. And we look forward to your PR! :smile: