Improvement idea: add `choice` prop to features giving a subclass

[Freedzio]

Just like the title says. There are feautres, where you choose something form an array of opitons, be it expertise, eldritch invocation or fighting style. Why not treat subclasses the same way?

Proposed structure:

{
    "index": "otherworldly-patron",
    "class": {
        "index": "warlock",
        "name": "Warlock",
        "url": "/api/classes/warlock"
    },
    "name": "Otherworldly Patron",
    "level": 1,
    "desc": [
        "At 1st level [yada yada]."
    ],
   "choice: {
        "choose": 1,
        "type": subclass
        from: "api/classes/warlock/subclasses"
    }
    "url": "/api/features/otherworldly-patron"
}

I know there is only one subclass in the SRD, but as y'all mentioned before, if something comes from a feature, you like to keep it within that feature, so why not add information about subclass choices to the feature giving you a subclass?

[fergcb]

I like this, but I think it would be nice if the choice property was nested under some kind of feature_specific attribute.

This would just keep the Feature model organised a bit more as we go through and add structures like this to all features. Rather than giving each different kind of feature (of which there are many) a different structure, we would be giving all features the same structure, where one of the attributes has an arbitrary shape (within reason).

{
    ...
    "feature_specific": {
        "subclass_option": { Choice<subclass> }
    }
}

[Freedzio]

Hmmm

Maybe put subclass giving features in feature_choices prop in data from classes/${class)/levels/${level} endpoint? This way, IMO there is even more consistency

Example:

data from level endpoint

  ...
    "feature_choices": {
         "index": "otherwordly-patron",
         "name": "Otherwordly patron",
         "url": "endpoint-to-that-feature"
    }

and then in the feature itself, the structure you proposed

[fergcb]

I dislike that, personally. The SRD doesn't read as allowing the character to choose between multiple features; it grants one feature that allows a choice of subclass.

If you allow a choice of subclass in feature_choices, then you're introducing an inconsistency where otherwise all the choices would be for features.

[Freedzio]

When you put it that way, ye, my propositon would stir some disinformation. feature_specific approach is cleaner. It indicates that this feature has some logic/complexity behind it and allows the api cosnumer to deal with it the way it needs to. Just like class_specific data

[Freedzio]

As I work on my app, I am having more and more ideas.

Given there will be feature_specific prop, how about putting there data about bonuses? For example, in Fighitng style: archery

...
feature_specific: {
    bonus: {
        type: "damage"
        amount: 2
        for: ["ranged"]
    }
}

or something among those lines. To make features more computer friendly

[fergcb]

Yeah, this is exactly what I meant when I was talking about how the feature_specific property would help keep things organised as we expand on all the features in this way.