Data schema design

[fcollonval]

With #17, tours can now be defined from JSON description. But I realize the steps attributes is duplicated:

{
        "type": "object",
        "required": ["id", "label", "steps"],
        "properties": {
          "id": {
            "type": "string",
            "description": "A machine-readble ID to identify this tour, will be prefixed. Should be unique within this document."
          },
          "label": {
            "type": "string",
            "description": "A human-readable name for the tour"
          },
          "hasHelpEntry": {
            "type": "boolean",
            "description": "Whether to add a Help Menu item with the label to launch the tour",
            "default": true
          },
          // HERE the steps
          "steps": {
            "description": "The definition of the steps of a tour",
            "type": "array",
            "items": {
              "$ref": "#/definitions/Step"
            }
          },
          // Steps are also HERE options.steps
          "options": {
            "description": "Other options for the tour",
            "$ref": "#/definitions/Props"
          }
}

@bollwyvl Should we keep only the steps in the options as they are/will be generated from Joyride types?

[fcollonval]

Another possibility would be to expand the options in the tour.

[bollwyvl]

Yeah, sorry I didn't make a note about that.

My thinking was:

• the command API already had steps...
  • didn't want to break back-compatibility
  • wanted to reuse types/test fixtures
• the steps...
  • get a separate page in the upstream docs
  • represent where most folks would spend their time configuring
  • would get a separate, dedicated UI
  • is slightly less nested