UIKit lineage still links to excluded patterns

[bmuenzenmeyer]

As part of #811 and #840 we delivered the ability to exclude patterns in a UIKit. This works for both the writing of the files and for them showing up in the navigation, but a pattern's lineage may still include an excluded pattern, causing a link to it appear. Clicking the link causes Pattern Lab to break.

The fix for this would involve combing through each pattern's lineage at the right time - likely right before build (?) within the context of individual uikits, so as to remove lineage nodes (both lineage and lineageR) from the pattern where the nodes are in the exclusion lists (state and tags).

[engelfrost]

As I understand states (which can also be excluded), a pattern of a higher state that includes a pattern with a lower state will inherit the lower state. Does excluding tags work differently by design? The other solution is of course to exclude any pattern that depends on an excluded pattern, since there is already have a concept of simply hiding patterns.

Asking because I can't find the answer in either of the two issues above.

[bmuenzenmeyer]

Does excluding tags work differently by design?

tags are a proposed system not yet implemented, but would not have an inheritance logic built atop them. they would be labels for use within filtering and sorting mechanism, like excludedTags for a UIKit

How we handle patterns that rely on excluded patterns is a good question. When initially envisioning this, I considered this exclusion visual only in the finished product, but what I instead implemented was a non-write. This creates problems anywhere the pattern can be navigated too (lineage, pattern links, search maybe) and therefore each should be considered. Right now users will get missing patterns errors.

Not sure if I answered your question. Curious, how do you think it should work?

[engelfrost]

Thanks, that pretty much answers my question.

What I thought excludedTags would do (based on it's name only) was exclude the tagged pattern, as well as any patterns dependent on that pattern. Example:

• molecules-y includes atoms-x
• atoms-x is excluded
• => molecules-y will be excluded since it depends on atoms-x.

To simply hide atoms-x from the UI, I would expect the feature to be called something "softer" than excluded. Perhaps hiddenTags? This seems to be what you describe above. This behavior seems identically to the underscore feature except for two things: _atoms-x.mustache does not cause lineage links to be removed, and cannot be configured per UIKit.

I'm not sure which of the two behaviors would be the most useful to me, I feel that I have too little experience with the idea to confidently answer your question.

• The "soft exclusion/hidden" solution would probably be useful when having a simple Workshop/Storefront solution and dealing with a reasonable number of patterns (which I assume is the most common case). There might be a risk of too much micro-management, and where the documentation becomes incomplete.
• The "hard exclusion" might be easier to work with when maintaining a large library and/or multiple Storefronts (a less common, but also more demanding case). The risk here might be that the exclusion tool becomes too blunt.