Add pattern export all #601

jwir3 · 2017-01-28T01:30:37Z

Use Case: We use pattern-lab to create a rough design, then export all of our styles and patterns to a rails web application. This PR seeks to make the export more user-friendly by:

Allowing us to export raw patterns (.mustache files) which can be interpreted by the ruby mustache template engine.
Preserving directory structure of our atoms/molecules/etc... such that we don't have too much directory hierarchy, but one level deeper than just a flat directory structure.
Allowing us to easily specify that we want all patterns to be exported, rather than having to manually specify each one (as our designs are in flux constantly right now, and there are many changes).

Summary of changes:

Add capability to export all patterns via a flag in patternlab-config.json.
Add capability to preserve rough directory structure via a flag in patternlab-config.json.
Add capability to export raw patterns via flag in patternlab-config.json.

Note: This is a sort of rough start to a PR. I don't expect that it's going to be approved initially, but rather it's more of a starting point. It doesn't conform to the pattern-lab spec, although, I do know PHP, and would be willing to change the pattern-lab PHP code as well as the node code (node just happens to be what we use right now), but I'm not 100% sure how to go about adding this to the spec. Typically, a proof-of-concept/starting-point implementation tends to be required before modifying a specification, anyway, so this should serve as that. (This is the reason the documentation for the new flags added in patternlab-config.json wasn't added).

Instead of prefixing patterns with "<category>-", we prefix the directory path with "<category>/".

Exporting "raw" patterns means that the export task is little more than a wrapper around a more condensed file naming method. Instead of outputting rendered HTML, the exporter outputs the raw patterns, augmented to remove any superfluous directory structure and prefixed ordering.

bmuenzenmeyer · 2017-01-30T04:02:23Z

First off - thank you SO much for your contribution. I greatly appreciate a thoughtful, thorough PR and look forward to working with y'all.

I am starting a review of this by comparing functionality against my build of PL PHP. Stay tuned.

bmuenzenmeyer · 2017-01-30T04:50:26Z

A short while later...

It looks like export in PHP does the following, and is considered current spec:

exports patterns/ preserving the file structure of the patterns
exported patterns represent their finished - rendered, compiled HTML
exports most of the contents of source
If you require your patterns to be exported without your global header and footer (e.g. to export a clean molecule) do the following... (see next comment)

So to me, that's the baseline we need to shoot for or address.

exports patterns/ preserving the file structure of the patterns

I think your flag covers the spirit of that feature, and feedback from the community can further determine if it needs to support pattern subgroup too. My thought would be most individuals would move them around to their liking in a production scenarion anyways.

exported patterns represent their finished - rendered, compiled HTML

Again, your flag covers this, and then some. Users can choose their own adventure with either raw or rendered patterns.

exports most of the contents of source

I am going to make a decsion say that this is not important. Modern toolchains make the copying of css/js/images/fonts from source/ to public/ or export/ trivial. PL doesn't need to do this in my opinion. Longterm, PL is going to get out of the business of moving assets around too much.

So, that being said, I am going to give this a 👍 conceptually, and it's a welcome addition to the capabilities of the library.

I will do some testing and then conduct a more formal review.

bmuenzenmeyer · 2017-01-30T06:12:49Z

I read through the docs and noticed one more thing:

If you require your patterns to be exported without your global header and footer (e.g. to export a clean molecule) do the following...

This will be something to strive for. Doing this will require either some ugly regex/substring work, a different core codepath, or something more creative. I will add it to the above. I still don't see this stopping the PR, as it's a step in the right direction.

I wonder then...

Allowing us to export raw patterns (.mustache files) which can be interpreted by the ruby mustache template engine.

Are you removing this somehow yourself?

EDIT Nevermind, I found out myself. With the current PR, the global head and foot are excluded. I suppose we could add another flag to include if a user wished. Might as well wait for feedback on that first.

bmuenzenmeyer

Left some comments which need to be addressed.

It would also be nice if this had some unit test coverage - but that's just extra credit.

bmuenzenmeyer · 2017-02-02T06:33:44Z

core/lib/pattern_exporter.js

+      }
+
+      return;
+    }

    //find the chosen patterns to export
    for (var i = 0; i < exportPartials.length; i++) {


I cannot think of a need to loop through a provided array if the user has chosen to export all. I suggest making these mutually exclusive. Should be simple to add this as an else block as part of the exportAll check

bmuenzenmeyer · 2017-02-02T06:51:39Z

core/lib/pattern_exporter.js

+    if (exportAll) {
+      for (var i = 0; i < patternlab.patterns.length; i++) {
+        if (!patternlab.patterns[i].patternPartial.startsWith('-')) {
+          exportSinglePattern(patternlab, patternlab.patterns[i]);


I'd suggest adding a check for to make sure patternlab.patterns[i].isPattern === true before calling exportSinglePattern() to avoid having the meta head and meta foot from being exported.

bmuenzenmeyer · 2017-02-02T06:52:30Z

core/lib/pattern_exporter.js

+
+    if (patternlab.config.patternExportRaw) {
+      patternCode = pattern.extendedTemplate;
+      patternFileExtension = "." + JSON.parse(pattern.patternData).patternExtension;


I have no idea what that JSON.parse is doing in there.

pattern.patternExtension suffices.

There is no pattern.patternExtension - "patternExtension" only lives within pattern.patternData - which does seem lto be a stringified JSON object (hence the parse @jwir3 added).

We do have a pattern.fileExtension available (which shows up with the period in it, such as .hbs. I'm guessing we could use this to clean it up, but I'm not sure to why we have this difference between fileExtension and patternExtension, and why patternExtension is only available in that weird string JSON patternData.

jwir3 · 2017-02-18T16:46:38Z

@bmuenzenmeyer Sure thing. Thanks for the review, I'll look at it as soon as I have a chance.

bmuenzenmeyer · 2017-10-02T12:26:52Z

@jwir3 how is it going? Any chance this work could be picked back up - or would you like me to take the baton?

jwir3 · 2017-10-02T14:30:30Z

@bmuenzenmeyer My apologies. I got distracted and forgot about this. I should have some time this week to finish this up. I'll get it to a point we discussed. Sorry for the delay.

bmuenzenmeyer · 2017-11-15T09:35:01Z

hello @jwir3 - still interested in finishing this? Just let me know if you would like me to pick it up

stale · 2018-01-14T10:11:04Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

J-Gonzalez · 2018-08-21T08:24:17Z

This PR allows us to actually export our handlebars templates in a smart fashion that allows them to be consumable by our applications in the same way they are used within PL. The directory structure works perfectly in allowing us to register all of our partials and add the directory name in order to mimic the naming structure used in PL ("atoms-button" or "molecules-card").

I think this approach (or something similar) would work great when thinking about #834 as it gives us a path towards exporting partials in the same way they are documented in PL.

bmuenzenmeyer · 2018-08-21T12:59:15Z

@J-Gonzalez thanks for the feedback. This PR remains important to me, but it's been waiting on response from the OP for a bit. I will likely take up the comments soon to get it into the codebase proper.

Glad its of value to you!

jwir3 · 2018-08-21T15:28:47Z

Yeah, I'm really sorry. I've been remiss in keeping this up to date. I just don't think I have the time to spend on it to really push it over the finish line. I would appreciate any help you guys could give!

bmuenzenmeyer · 2018-08-21T15:40:57Z

@jwir3 no worries. believe me, I understand we all operate at the speed of open source (make what you will of that).

Your initial work is already of value, and it's good to hear from you again!

bmuenzenmeyer · 2019-10-29T12:28:43Z

1005 days later....

this is good work @jwir3 - glad it will finally see the light of day!

jwir3 added 3 commits January 27, 2017 19:22

Add a configuration option to export all patterns.

19b0cce

Make pattern export optionally preserve directory structure.

410032e

Instead of prefixing patterns with "<category>-", we prefix the directory path with "<category>/".

bmuenzenmeyer self-requested a review January 30, 2017 02:27

bmuenzenmeyer self-assigned this Jan 30, 2017

bmuenzenmeyer requested changes Feb 2, 2017

View reviewed changes

bmuenzenmeyer added the needs review from op label Feb 2, 2017

bmuenzenmeyer removed their assignment Feb 9, 2017

stale bot closed this Oct 2, 2017

bmuenzenmeyer reopened this Oct 2, 2017

stale bot removed the needs response label Oct 2, 2017

stale bot added the needs response label Jan 14, 2018

stale bot closed this Jan 21, 2018

bmuenzenmeyer reopened this Jan 22, 2018

stale bot removed the needs response label Jan 22, 2018

bmuenzenmeyer added the pinned 📌 Don't let stalebot clean this up label Jan 22, 2018

bmuenzenmeyer self-assigned this Aug 21, 2018

bmuenzenmeyer merged commit 436dd99 into pattern-lab:dev Oct 29, 2019

bmuenzenmeyer mentioned this pull request Oct 29, 2019

feat(config): add new default pattern export options #1089

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add pattern export all #601

Add pattern export all #601

jwir3 commented Jan 28, 2017

bmuenzenmeyer commented Jan 30, 2017

bmuenzenmeyer commented Jan 30, 2017 •

edited

Loading

bmuenzenmeyer commented Jan 30, 2017 •

edited

Loading

bmuenzenmeyer left a comment

bmuenzenmeyer Feb 2, 2017

bmuenzenmeyer Feb 2, 2017

bmuenzenmeyer Feb 2, 2017

J-Gonzalez Oct 30, 2018

jwir3 commented Feb 18, 2017

bmuenzenmeyer commented Oct 2, 2017

jwir3 commented Oct 2, 2017

bmuenzenmeyer commented Nov 15, 2017

stale bot commented Jan 14, 2018

J-Gonzalez commented Aug 21, 2018

bmuenzenmeyer commented Aug 21, 2018

jwir3 commented Aug 21, 2018

bmuenzenmeyer commented Aug 21, 2018

bmuenzenmeyer commented Oct 29, 2019

Add pattern export all #601

Add pattern export all #601

Conversation

jwir3 commented Jan 28, 2017

bmuenzenmeyer commented Jan 30, 2017

bmuenzenmeyer commented Jan 30, 2017 • edited Loading

bmuenzenmeyer commented Jan 30, 2017 • edited Loading

bmuenzenmeyer left a comment

Choose a reason for hiding this comment

bmuenzenmeyer Feb 2, 2017

Choose a reason for hiding this comment

bmuenzenmeyer Feb 2, 2017

Choose a reason for hiding this comment

bmuenzenmeyer Feb 2, 2017

Choose a reason for hiding this comment

J-Gonzalez Oct 30, 2018

Choose a reason for hiding this comment

jwir3 commented Feb 18, 2017

bmuenzenmeyer commented Oct 2, 2017

jwir3 commented Oct 2, 2017

bmuenzenmeyer commented Nov 15, 2017

stale bot commented Jan 14, 2018

J-Gonzalez commented Aug 21, 2018

bmuenzenmeyer commented Aug 21, 2018

jwir3 commented Aug 21, 2018

bmuenzenmeyer commented Aug 21, 2018

bmuenzenmeyer commented Oct 29, 2019

bmuenzenmeyer commented Jan 30, 2017 •

edited

Loading

bmuenzenmeyer commented Jan 30, 2017 •

edited

Loading