Spells V2 discussion

[augustjohnson]

I propose that spells is the first data type that gets it's own v2 endpoint, with breaking changes to the format of the spells.

Adding a distinct endpoint is depended on concensus on an approach on #145. This space is the wishlist for use cases for an API v2 endpoint. Here's my start:

• Filter spells by class (multiple classes allowed).
• Sort spells by casting time.
• Sort spells by length.
• Filter spells by damage type (multiple).
• Spell component VSM list filterable as well.

Stretch goals: some sort of model for "higher level" ? Damage description strings at a given level? I.e. I say "casting at level 5" and it says "5d8 + Spellcasting modifier" damage or something.

[augustjohnson]

A few other use cases that are pretty much required.

• Filter spells by document source, (multiple).
• Strong validation on input, for example an import file must have [V,S,M] in order, not [V,M,S] or something like that.

[augustjohnson]

Daaaaang this looks good: https://alchemyrpg.github.io/slate/#spell

The idea would be: Conform to their output 1 to 1. Maybe add a few fields here and there for sort order and such, but overall, that.

[augustjohnson]

Model changes required to be able to conform to this:

components would need to change from a text to a list of strings. would need to add CanCastAtHigherlevel boolean need to change Ritual to boolean damage (probably new Model?) would need to be specified. some concept of Higher Levels modifications of the spells. Both "higher level description" and a more detailed one. There's a rollsAttack boolean that's pretty useful. There's a savingThrow field that specifies an ability I believe.

[augustjohnson]

I'm going to considered this delivered at this point. Specifics can be made into other tasks.