jesconstantine
commented
7 years ago @cybtachyon very excited to see this issue over at the Commonwealth of Massachusetts! On the openmass project we are using a custom module (named after our Pattern Lab design system) to handle data mapping, transformation and structuring. It's resulted in a developer-centric process for adding content types and patterns. I'd love to see the community standardize on a method that takes advantage of site building and Drupal's UI to handle some of this.
Something that I think ties into some of the projects you've listed above is using pattern data structure "documentation" or "definition" (via json schema for pattern builder and yml definition files for ui patterns) in that data mapping process. I think it would help the community to standardize on a format for this definition / documentation and have those files live in Pattern Lab (much like the json schema files live in pattern kit).
What I really like about the way that pattern builder / pattern kit uses json-schema is that it serves multiple purposes:
- documentation for implementers / consumers of patterns
- something to validate actual pattern data (json) against
- a blueprint from which to create webforms BOTH in Drupal (i.e. pattern builder module creates paragraph edit forms) AND in PatternKit (i.e. a "schema editor" tab which allows for both content prototyping and pattern variant / assembly in real time) -- imagine the potential here!
For those reasons json schema would get my vote, but I suspect there are ways to accomplish multiple purposes with yml or some other format as well.
Should I create an issue on the roadmap and link to it from here?
EvanLovely
cybtachyon
sghoweri
micahgodbolt
evanmwillhite
bradfrost
bmuenzenmeyer
SiliconValet
mariohernandez
Summary:
Benefits:
To Do:
One of the hard problems with making Drupal play nice with a pattern library is mapping your backend Drupal entities and fields to the pattern variables. Some patterns expect strings, or arrays, or can even accept complicated objects for rendering that make use of recursive rendering from the parent platform.
This would be relatively simple to solve if we just use schemas for our patterns and imported those at run-time into Drupal. Unfortunately for that approach, many Drupal sites have a complicated set of backend data, entity, and field organization that makes it impossible to map fields 1:1 to a frontend. This also makes it hard to dynamically generate data models in Drupal for all scenarios, since often we’ll want to include values contained in other fields/entities.
1:1 mapping is easier though than tackling data mapping, and there are a couple of solutions that implement it pretty well.
A common solution for data mapping in Drupal 8 is to use “presenter” twig templates that include a pattern from the library and do all the complicated data mapping in the Drupal “presenter” template. This essentially looks like:
One possible solution is to use a Pattern Renderer API service, that allows a configuration tool to display and set replacement tokens for Drupal to manage. The issue with this is that it relies on developers to create those tokens for all of the backend data.
Another possible solution is to have a Drupal module that has a configurable set of data mapping transformations, much like Views, that allows assigning fields to the pattern schema variables.
Here are some of the current open source community attempts at solving this problem, in order of scope from smallest to largest:
The teams I work with internally already have a number of projects in this vein and are planning on moving forwards with a consolidated project starting August 21st.
cc @ThatGuyCND @EvanLovely @evanmwillhite