Discussion & Vote: Describing State in Config

[dmolsen]

A user wants to quickly define pattern states and their options for Pattern Lab.

---

After looking through the docs the current implementation of pattern states is a bit awkward and indirect from a customization perspective. To implement a color for a state someone must edit a CSS file. Which one? Not sure there's a great choice. There's also no way to give a default state to all the things. I'd like to propose that we expand the pattern state configuration. From a PHP perspective if we expand this to a config then developers would have many hooks for defining pattern state (e.g. from a StarterKit or an Edition).

System Input: Configuration

The current configuration in PHP is an array that simply lists pattern states in order of inheritance. A pattern state is added as a class in the output of the front-end. An example:

patternStates:
    - inprogress
    - inreview
    - complete

A new configuration would continue to be an array of pattern states in order of inheritance but each pattern state could have an OPTIONAL array of attributes. This would maintain backwards compatibility because we could check the pattern state value. If it's a string it's the old format or it should just be handled as a class name. If it's an array save the attributes and use the key as the class name. An example:

patternStates:
    - inprogress:
       - title: In Progress
         description: This is a description
         color: #444
         default: true
    - inreview:
        - title: In Review
          description: This is a description
          color: #555
    - complete:
        - title: Complete
          description: This is a description
          color: #666

I'm not sure if title or description would really find their way into the front-end but better to build them in now. title tag on pattern state-related link maybe?

In System Use

If any state sets default to true then that state is the base from which all pattern state inheritance works if a pattern state isn't explicitly defined for a pattern. Currently we explicitly define it using @state but will be switching to state: inprogress in the *.md files.

System Output

For the most part this is the same as it is currently. Patterns will have a state. Otherwise the configuration option patternStates could be passed whole to the front-end and styleguidekit-assets-default could check for it and build styles/tags as appropriate with the template.

The timeline for this feature is not critical.

Tagging spec-enhacement, core and front-end/shared because it affects an input to Pattern Lab and an output to styleguidekit-assets-default.

This vote will close at 9PM EST on July 22 or once two of the voting members have voted yay or nay.

/cc @pattern-lab/voting-members

[bradfrost]

I think this is super smart thinking. And yep, I think it's smart to bake in the title/description now, and yep use it as a title on the link on the frontend. Alternatively, we could make the indicator its own DOM element that could trigger a tooltip or something.

But ultimately, yes I'm all for this direction! The only thing I'm opposed to is the timeline, since I'm starting off a massive project and want to bake status into our workflow right out of the gate :).

[bmuenzenmeyer]

You can add status frontmatter to any pattern.md file now and it will flow through when implemented on PHP. What's discussed here is just better config of all statuses

On Sat, Jul 9, 2016, 8:12 AM Brad Frost notifications@github.com wrote:

I think this is super smart thinking. And yep, I think it's smart to bake in the title/description now, and yep use it as a title on the link on the frontend. Alternatively, we could make the indicator its own DOM element that could trigger a tooltip or something.

But ultimately, yes I'm all for this direction! The only thing I'm opposed to is the timeline, since I'm starting off a massive project and want to bake status into our workflow right out of the gate :).

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/pattern-lab/the-spec/issues/22#issuecomment-231533885, or mute the thread https://github.com/notifications/unsubscribe/AASNwyOwFCli6Bd3BIJ2rIwcCE7XF23Iks5qT547gaJpZM4JIg02 .

[bradfrost]

Ah yeah that's smart! Thanks.

[dmolsen]

Just to make this official and passed, Brad can you give this a thumbs up, please? That's how we track votes. Literally the +1 emoji thingie. Like my vote:

:+1:

[bmuenzenmeyer]

My comment the other day was mobile and hasty - so I didn't think to vote.

:+1: on my end FWIW

[dmolsen]

updated labels

[bradfrost]

👍