mark.ie: Can I Stop PatternLab Variants from Inheriting Data from their Parent Component

Can I Stop PatternLab Variants from Inheriting Data from their Parent Component

I have a card component with a title, image, text, and link. How come all my card variants are inheriting all the values from the default one? Short answer, you don’t. It’s a feature, not a bug.
markconroy
Fri, 10/19/2020 – 13:01

Where this really becomes frustrating is when you have a pattern that lists a number of items in an array. In that case, all variants will have (at least) that many items, even though you may want fewer.

For illustration:

list.twig has something like this:

{% for list_item in list_items %}
  {{ list_item }}
{% endfor %}

Then list.yml has something like this:

list_items:
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser
  – join():
    — loads of more teasers for the main listing page

Now you want to create a variant of list such as list~related-articles, but with only 2 items. You’d expect this would worklist_items:
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser

But, no. This will still render as many items as were in the parent component. That’s the beauty (a feature, not a bug) of PatternLab’s inheritance system. To stop it you need to do something like this:

list_items:
  – join():
    – include():
        pattern: content-teaser
  – join():
    – include():
        pattern: content-teaser
  –
  –
  – and so on, so each extra one is basically set to ‘false’

When we do this with a component such as a card, we might also want to have variants such as card~no-image, card~no-text, etc. In this case, we’d have a card.yml like so:

card_title: ‘My Card Title’
card_image: ”
card_text: ‘The text of the card will go here’

However, if we create variants, each of the items in card will be inherited to the variant. You’ll notice this if you try to create one super mega component for all variants of a hero component for example (hero title, pre-title, sub-title, image, alignment, cta buttons, etc).

In this case, what I do is create a default component card.yml or hero.yml and give it only values for items that will more than likely be in all variants (basically whatever you are going to mark as a required field in Drupal maintenance support plans (or whatever CMS you are using)), then set all others to ‘false’ in the component. Now when I create variants I only need to override the specifics for that variant, since everything else that is being inherited is already set to false. I also create a ‘Kitchen Sink’ version of the component which shows every item in action but DO NOT create this as the default/reference component.

My default card.yml might look like this:

card_title: ‘My Card Title’
card_image: false
card_text: false

Now my variants can look as simple as:

card~with-image.yml
card_image: ”

And card~long-title will be just one line:

card_title: ‘This is a long title on a card just to illustrate what happens when it wraps to more than one line’

And that is why this is a feature, not a bug – it allows us to write variants very simply and quickly. Is there a better way of doing this? I’m not aware of one. If you are, drop it in the comments. Thanks.


Source: New feed

This article was republished from its original source.
Call Us: 1(800)730-2416

Pixeldust is a 20-year-old web development agency specializing in Drupal and WordPress and working with clients all over the country. With our best in class capabilities, we work with small businesses and fortune 500 companies alike. Give us a call at 1(800)730-2416 and let’s talk about your project.

FREE Drupal SEO Audit

Test your site below to see which issues need to be fixed. We will fix them and optimize your Drupal site 100% for Google and Bing. (Allow 30-60 seconds to gather data.)

Powered by

mark.ie: Can I Stop PatternLab Variants from Inheriting Data from their Parent Component

On-Site Drupal SEO Master Setup

We make sure your site is 100% optimized (and stays that way) for the best SEO results.

With Pixeldust On-site (or On-page) SEO we make changes to your site’s structure and performance to make it easier for search engines to see and understand your site’s content. Search engines use algorithms to rank sites by degrees of relevance. Our on-site optimization ensures your site is configured to provide information in a way that meets Google and Bing standards for optimal indexing.

This service includes:

  • Pathauto install and configuration for SEO-friendly URLs.
  • Meta Tags install and configuration with dynamic tokens for meta titles and descriptions for all content types.
  • Install and fix all issues on the SEO checklist module.
  • Install and configure XML sitemap module and submit sitemaps.
  • Install and configure Google Analytics Module.
  • Install and configure Yoast.
  • Install and configure the Advanced Aggregation module to improve performance by minifying and merging CSS and JS.
  • Install and configure Schema.org Metatag.
  • Configure robots.txt.
  • Google Search Console setup snd configuration.
  • Find & Fix H1 tags.
  • Find and fix duplicate/missing meta descriptions.
  • Find and fix duplicate title tags.
  • Improve title, meta tags, and site descriptions.
  • Optimize images for better search engine optimization. Automate where possible.
  • Find and fix the missing alt and title tag for all images. Automate where possible.
  • The project takes 1 week to complete.