Support for {{ message }} default value

[theorise]

It would be great to be able to have a fallback / default value when using {{message}}. You can define a {{message}} when including a pattern, however there is no way of making it optional.

---

The current situation is as follows:

Pattern: (atom)

<p>{{message}}</p>

Pattern call: (molecule)

{{> atoms-pattern(message: "100,00") }}

Output when viewing molecule:

<p>100,00</p>

Output when viewing atom:

<p></p>

---

An ideal way would be for there to be a fallback / default value which the {{message}} would overwrite if present:

Pattern: (atom) - using a string

<p>{{message:"50,00"}}</p>

Pattern: (atom) - using _data.json

<p>{{message:data.value}}</p>

Pattern call: (molecule)

{{> atoms-pattern(message: "100,00") }}

Output when viewing: (molecule)

<p>100,00</p>

Output when viewing: (atom)

<p>50,00</p>

[bmuenzenmeyer]

I'm a little confused by this.

<p>{{message:data.value}}</p>

If I recall, this is not really valid mustache? It's certainly not a pattern partial like:

{{> atoms-pattern(message: "100,00") }}

I'll take a look at this, as with the other issues, sometime soon. Thanks for contributing and your interest in pattern lab node.

[theorise]

Sorry, the syntax was bad.

I mean something similar to this suggestion. Having an option to be able to use a {{message}} with a fallback. If the pattern being called with an include does not have a message parameter defined, a default value is there to fall back on.

Thanks for all the work you are doing for PL node!

[bmuenzenmeyer]

Interesting. The linked issue pertains to styleModifiers, which I understand and agree would be neat!

Default values should be found in data.json so they are used if a pattern does not supply it's own pattern parameters. Are we talking about two different things? Sorry for my confusion.

[theorise]

The scenario I have is the following:

I have a component for a price that has three states and is wrapped in a price-group.

When a price is unchanged: <span class="price"> - the standard way of displaying a price

When a price is discounted, two prices are displayed: <span class="price price_original"> - displaying the original price with a strikethrough <span class="price price_discounted"> - displaying the discounted price in red

The standard price atom could be built like:

<span class="price {{styleModifier}}">
    {{message}}
</span>

Then I can create the variant atoms this way:

{{> atoms-price:price_original(message: "{{price.original}}" ) }}

and:

{{> atoms-price:price_discounted(message: "{{price.discounted}}" ) }}

This method enables controlling variants of {{styleModifiers}} and {{messages}} and is much easier to maintain. The problem here is that the original price atom has no value set and therefore cannot be viewed at atomic level.

It would be possible to create a price-skeleton that takes form of the original atom, then creating a price-original, but that is where you come across the bug I logged. It is also not as easy (obvious) to maintain.

What would be nice is to be able to do the following:

<span class="price {{styleModifier}}">
    {{message(fallback: "{{json.data.val}}") }}
    {{message(fallback: "Fallback string}") }}
</span>

That way when I visit the price default atom I get a value displayed, instead of seeing nothing.

---

Maybe I am not understanding how to arrange my atoms properly. When I look at the demo - http://demo.patternlab.io/?p=atoms-headings I see the headings on atomic level are all present.

I do not feel like this is the ideal way of working. What happens if I have a component that has a specific header that I can just call with {{> atoms-header-1(message: "Heading value") }} rather than coding it?

If the heading markup changes the user is going to have to change it in every other molecule, organism, etc. that has a heading in it, rather than just changing it in a single mustache file at atomic level. It looks like it could become a maintenance nightmare.

[bmuenzenmeyer]

Hi @theorise

Maybe I am not understanding how to arrange my atoms properly. When I look at the demo - http://demo.patternlab.io/?p=atoms-headings I see the headings on atomic level are all present.

The demo works (PLPHP by the way, not PL Node) because the HTML is:

<h1>Heading Level 1</h1>
<h2>Heading Level 2</h2>
<h3>Heading Level 3</h3>  
<h4>Heading Level 4</h4>
<h5>Heading Level 5</h5> 
<h6>Heading Level 6</h6>

You can confirm this by pulling up the code view. Indeed, not maintainable, and clearly not intended to be consumed by larger atomic design elements.

The problem here is that the original price atom has no value set and therefore cannot be viewed at atomic level.

I completely understand where you are coming from with wanting atomic-level default values. I accomplish this myself by leveraging the data.json file found within ./source/_data

I'd create a record like:

"heading" : "Heading"

and then make atoms-header-1:

<h1>{{heading}}</h1>

This should let the default display, unless a pattern parameter is specified or it's otherwise overwritten by a large template. In the parameter case, this should then work:

{{> atoms-header-1(heading: "A Different Heading") }}

Does this meet your needs? Things get a little dicey if you use nested data.json objects but so far I haven't really had any growing pains keeping things flat. That's just me, however.

[theorise]

Thank you for the response @bmuenzenmeyer.

I had absolutely no idea you could use anything other than 'message' in the pattern include argument, now I feel stupid!

Your reply covers everything I was asking and more. Unfortunately it just revealed a couple of bugs.

You are not able to use anything over than the top level of data.json: https://github.com/pattern-lab/patternlab-node/issues/189

Unset styleModifiers seem to inherit a class despite not being set: https://github.com/pattern-lab/patternlab-node/issues/190

[bmuenzenmeyer]

I am closing this as a resolved issue.