Param groups

[funwithtriangles]

It should be possible to organise params and shots into collapsible groups with sub headers. Either by defining the groups in one place and then tagging shots and params, or just by having a nested structure.

Tagging:

{
   paramGroups: [
      {
         title: 'Lorem Group',
         key: 'lorem'
      },
      {
         title: 'Ipsum Group',
         key: 'ipsum'
      }
   ],
   params: [
     {
        title: 'Foo',
        key: 'foo',
        group: 'lorem'
     },
     {
        title: 'Bar',
        key: 'bar',
        group: 'ipsum'
     }
   ]
}

Nested:

{
   paramGroups: [
     {
        title: 'Ipsum Group',
        params: [
        {
           title: 'Foo',
           key: 'foo',
        },
        {
           title: 'Bar',
           key: 'bar',
        }
     } 
   ]
}

[funwithtriangles]

@netgrind I think this should be completed before any of the other param config stuff. What's your preferred syntax option?

[cale-bradbury]

I like tagging more as it becomes easy to leave the groups out/adding them down the line. I'd like to suggest reversing the tagging order though.

{
   paramGroups: [
      {
         title: 'Lorem Group',
         elements: ['foo', 'fizz', 'bang']
      },
      {
         title: 'Ipsum Group',
         elements: ['bar']
      }
   ],
   params: [
     {key: 'foo' },
     {key: 'bar' },
     {key: 'fizz' },
     {key: 'bang' },     
   ]
}

my thoughts are that it makes it easy to quickly see what is in the group, has a very clear indication of what order elements will appear within the group, keeps the grouping all in one place.

It might also be a good idea to allow a description within the group, would let us add a collapsable global description of the effect easily, and give clarification for individual chunks of params.

paramGroups: [{
         title: 'Description Example',
         elements: [], //or just don't even include this element
         description: 'imagine a long description, this could be the very first group, no vars, but I'm nicely colapsable after you have read what this sketch is about, this field could also just not exist'
}]

[cale-bradbury]

Feels really good to be thinking about all this stuff! Important to figure out a target for the whole of the config/ui system and how the bits will play together

[funwithtriangles]

I think your way of doing the tagging makes most sense! I'm also totally for a description property. Sketches at the top level should also have this.

We might want the groups to have a mandatory key property too, just for indexing reasons. Although if we can avoid that's probably cleaner.

We could also have a openByDefault property, which authors could set to false if it makes sense for that group to usually be hidden.

[cale-bradbury]

openByDefault is a good call. In terms of a sketch-level description, It definitely feels cleaner than creating an empty param group. Wonder if by that logic it makes sense to give everything a description (for a param it would appear as a tooltip maybe?)