A spec for "Liquid Components"

[jaredcwhite]

Good morning! I posted this over at the Shopify/liquid GH repo and thought you might be interested here as well…trying to get some community feedback.

---

Hi everybody! A proof-of-concept implementation of what I'm calling the "Liquid Components" spec has just landed in the Bridgetown project.

PR: bridgetownrb/bridgetown#26

Demo: https://deploy-preview-26--bridgetownrb.netlify.app/components/

Preliminary spec: https://github.com/bridgetownrb/liquid-component

---

Essentially, the idea is that a Liquid template used by the render tag can contain YAML front matter at the top, which gets stripped out in our implementation of the File System.

That front matter then can be used by a tool that loops through all the templates and pulls out that metadata for use in building a "Storybook" style UI that documents the components. We also have sidecar "preview" files that are simply HTML to render out components as examples, and it's even possible to use per-component stylesheet partials as part of the Webpack build.

I'd love your feedback and further ideas of what this could do for the Liquid ecosystem and the ways in which templates and the render tag (along with our custom rendercontent block tag that processes HTML/Markdown body content) could be used to create pretty sophisticated design systems.

[jaredcwhite]

@harttle If I were to try to implement a simple function to strip the YAML front matter off a template before parsing it as Liquid, is that something you'd like to see as a PR for this library, or would you prefer it as a separate plugin of some kind? I'm not familiar with the internals of LiquidJS so I'm wondering about the best approach. I already have a Ruby implementation done now in https://github.com/bridgetownrb/liquid-component and would like a similar JS one so it's fully cross-platform.

[harttle]

It's better be implemented as a plugin until it's already supported or merged by shopify/liquid.

But currently the plugin API is specifically designed for custom filters and tags, so there may be needs for new APIs or hooks for the parser. It's perfectly OK to adjust that part of liquidjs to fit your need.

[jaredcwhite]

That makes sense. This is mainly related to the "render" tag, so whatever the virtual "filesystem" is that locates a template for the tag, I'd want to hook into that with a plugin to strip the YAML out before Liquid tries to parse the template.

I'll dig in a bit and keep you posted. Thanks!