Skip to content

Instantly share code, notes, and snippets.

@davatron5000
Last active August 29, 2015 14:00
Show Gist options
  • Star 10 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save davatron5000/5dcb5d026282c89c48f5 to your computer and use it in GitHub Desktop.
Save davatron5000/5dcb5d026282c89c48f5 to your computer and use it in GitHub Desktop.
Pattern Lab Thoughts

I love PL and the work that Dave and Brad have been doing. This is just random bullshit I've been thinking after a week of Pattern Lab use. Just

1. Just a source directory?

I've found that working on my current Pattern Lab, the only directory I really need is the source directory. That makes me think that all the config|core|extras|etc folders could not exist or be hidden from the user. That way a generic Node process that could be used by grunt, gulp, broccoli, etc might be beneficial. The "engine" is hidden from the user. Then updates could be seamlessly injected where now it'd be a bit of a manual process.

I think the simplicity of just having the files you're working on decoupled from the technology would be great for onboarding new users. Edit your source files (now at the project root) and point a nodeapp/grunt/gulp task at it.

It feels like a question of do you want it to be WordPress for patterns (engine coupled) or a Jekyll for patterns (engine decoupled/hidden).

Relevant links:

2. YAML/JSON instead of Ordinal Folders?

I've wondered if it's easier to just update some JSON instead of keeping folder and file names numerically prefixed. If you delete a pattern, it's a bit of work to re-ordinate all the other files (lots of git changes, etc).

This would maybe help in up-cycling patterns into a larger system (which is a lot of people's dream). I can then tell a backend developer to include() the molecules/global/pagination.mustache instead of molecules/02-global/03-pagination.mustache/, where the numbers seem subject to change. PL could then start existing within a directory of a larger system.

3. Extensions?

I talked with Brad about this, I know it's on the roadmap. I wonder if Jekyll's _plugins structure might be good here, and those are little web components (HTML/CSS/JS ... Polymer?) that inject features in to the style guide header. Extensions could be included/excluded using YAML/JSON as well.

@levito
Copy link

levito commented Sep 24, 2014

Here it is: https://github.com/levito/living-styleguide

I'd love to hear your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment