Including same atoms with different param

[coding-stuff]

This app is great but IMO in order for atoms to operate in their correct and most useful capacity there should be a way to include patterns with parameters (And not using JSON data).

(Note: I've read the documentation fully and have not found any method of doing what I'm about to describe/ if this is more of a mustache issue please let me know)

the best example I can give is of an input to explain what necessitates this type of capability. When I look at the form element atoms in the demo I see a group of different text inputs (with very similar if not the same exact styling). The variations that exist from input to input, however, are marginal, and consist mainly of placeholder, type, value differences etc.... First it seems impractical to store multiple atoms in one file as it makes the file useless except for display purposes (which i believe to be rightfully the job of a molecule that would group specific atoms based on context), input atoms should go one to a file, and be included by molecules based on context. example:

[login form molecule]

    {{ > atoms-input-username }}

    {{ > atoms-input-password  }}

    {{  > atoms-input-submit     }} 

[/login form molecule]

Currently in the molecules files demo there is html markup for atoms, rather than {{> pattern includes }}. Now before someone reminds me this is totally optional and that i can include atoms rather than writing out the full markup, let me get to the point:

Using the above example, let's assume the only difference between the atoms/input-username and atoms/input-password was the placeholder and value attributes. It seems counter intuitive to create two atom files for such minor differences. Instead I think the best way to go about it would be to include multiple instances of the same pattern with different param. maybe something like:

[login form molecule]

   {{ > atoms-input (placeholder: username) }}

   .....

[/login form molecule]

JSON data is limited, in that we are forced to use the same data for every instance of the pattern, and it is at very least unlikely for an atom to have the same context in every instance on a page, which also calls for the use of param with pattern includes. Otherwise, we'd have to make a file for every possible variation of the same atom.

Another example would be in the case where a text input had a certain icon appended to the left of it (imagining we had hundreds of icons to choose from using a library like font-awesome or so). Of course we don't want to create 300 separate text inputs for every icon. Rather, we'd include each input atom from a molecule and passing each input a value based upon the context of use.

[login form molecule]

   {{ > atoms-input (icon: user, placeholder: username) }}

   {{ > atoms-input (icon: lock, placeholder: password) }}

   .....

[/login form molecule]

Anyway, if there is something that I missed in the documentation that does this in a better way, please let me know. thanks.

[dmolsen]

@coding-stuff -

This is a really interesting idea. You aren't "forced to use the same data for every instance of the pattern" though the method for working around that would feel quite hack-ish and isn't documented. This would be more... explicit. I had already been playing around with the idea of modifying pattern styles (see #34) and this would make an interesting format for expanding on that idea.

I don't think this will be implemented before January but I'll leave this issue open so we make sure to address it. Thanks for the feedback.

[bradfrost]

I actually really like this idea. As someone who isn't (or at least wasn't until recently) a fan of JSON and external data, having the ability to quickly include a pattern and fill it with stuff is a nice thought.

There would less jumping around to change a headline, excerpt, image path, or whatever. I still think the JSON is useful as you can handle external data sources easily and also handle large chunks of data without stumbling over HTML chunks. But I really like this as a quick-and-dirty, close-proximity way of filling patterns.

My question is: can Mustache do this or is this running into its limitations?

[coding-stuff]

"My question is: can Mustache do this or is this running into its limitations?"

@bradfrost my question exactly. Actually I'm researching that right now.

My main point was, where the whole idea of atomic design is concerned, a molecule is a combination of atoms, and atoms exist (or should exist) only relatively - without (much if any) context. A molecule gives purpose to the atom and not the other way around, which lends more credibility to the idea of param, where the molecule (or any other parenting element for that matter) is able to determine the context of child elements (atoms in this case) where css is limited (.molecule > .atom) - like passing a data-attr etc...

@dmolsen

https://github.com/pattern-lab/patternlab-php/issues/34 seems like this is actually on a similar track with what I'm thinking. Also I'm interested in knowing what the hack is. I've read a bit of the source code, trying to get a feel of this app so maybe I could contribute to the project, already forked it.

[dmolsen]

@bradfrost -

This feature wouldn't use Mustache directly. This would just be a simple key:value string replacement feature that we can build into PatternLoader.php. So when a pattern partial is loaded we run through the given keys and values (e.g. (icon: lock, placeholder: password) ) and just do a find and replace.

I'm not sure long strings of text would work well in this format. I also wouldn't want to get into iteration of items like lists. You also wouldn't be able to pass variables from one pattern into another to be used in a pattern even further down the chain. Meaning that this wouldn't work:

-- a template references the organism header
{{> organisms-header (placeholder: foo) }}

-- the organism header references the molecule search box
{{> molecules-search }}

-- the molecule search box has a placeholder var
<input type="text" placeholder="{{ placeholder }}">

That said, you could use JSON at this point assuming placeholder was only referenced once. Alternatively, the placeholder var name could be set to something a little more unique that references the atom it's in like search-placeholder.

Anything more complicated than this would probably start running into the limitations placed on us by the nesting nature of PL. It wouldn't necessarily be the fault of Mustache.

[dmolsen]

@coding-stuff -

It'd have to be hacked in at line 103 of PatternLoader.php. Basically, parse the "name" of the partial which, from your example, I think Mustache would see as atoms-input (placeholder: username). So a bit of splitting of elements by spaces and what not. Send the first element, atoms-input, off to be parsed by getFileName, load the file into a var using file_get_contents(), use they key:value pairs (e.g. placeholder: username) for string replacement on that var, and then return the modified content to the overall Mustache lib to be parsed normally.

[bradfrost]

One other thought: I know this kind of thinking is a lot of what Web components is doing. So maybe it's worth looking into that a little more to get some ideas around structure, syntax, etc.

On Sunday, November 24, 2013, Dave Olsen wrote:

@coding-stuff https://github.com/coding-stuff -

It'd have to be hacked in at line 103 of PatternLoader.phphttps://github.com/pattern-lab/patternlab-php/blob/master/builder/lib/Mustache/Loader/PatternLoader.php. Basically, parse the "name" of the partial which, from your example, I think Mustache would see as atoms-input (placeholder: username). So a bit of splitting of elements by spaces and what not. Send the first element, atoms-input, off to be parsed by getFileName, load the file into a var using file_get_contents(), use they key:value pairs (e.g. placeholder: username) for string replacement on that var, and then return the modified content to the overall Mustache lib to be parsed normally.

— Reply to this email directly or view it on GitHubhttps://github.com/pattern-lab/patternlab-php/issues/62#issuecomment-29157653 .

---

Brad Frost http://bradfrostweb.com http://twitter.com/brad_frost

Sent from a tiny computer that fits in my pocket and also happens to make phone calls.

[dmolsen]

@bradfrost -

From my very limited experience with that tech that would definitely be running into the limitations of Mustache ;)

[patternlab]

Yeah, obviously that would. I'm just saying it might be worth looking into web components for inspiration.

On Sunday, November 24, 2013, Dave Olsen wrote:

@bradfrost https://github.com/bradfrost -

From my very limited experience with that tech that would definitely be running into the limitations of Mustache ;)

— Reply to this email directly or view it on GitHubhttps://github.com/pattern-lab/patternlab-php/issues/62#issuecomment-29158740 .

---

Brad Frost http://bradfrostweb.com http://twitter.com/brad_frost

Sent from a tiny computer that fits in my pocket and also happens to make phone calls.

[heroheman]

stumbled upon this node.js snippet a few months ago. maybe usefull for you guys. takes a mustache-"like" syntax and accepts params. https://gist.github.com/millermedeiros/3498183

[coding-stuff]

Just submitted a quick patch for this issue, any feedback would be appreciated.

view the source here: https://github.com/pattern-lab/patternlab-php/pull/65/files

Syntax for using param on pattern includes is as follows:

{{ > patternType-patternName (param1: value, param2: value2 ... ) }}

commas and parentheses have to be escaped with backslashes. example:

(param_name: A string using commas\, and parentheses () )

[dmolsen]

For those following along... I've commented on the patch in #65. Looks good though.

[dmolsen]

The rewritten version of this feature has been merged into dev. I'm closing just to get the overall issues list under control.