Re-architect how ui's are built

[bmuenzenmeyer]

As a user, I want to be able to generate multple UIs from a single pattern tree.

We will basically support a workflow first described in @bradfrost's article, The Workshop and the Storefront.

Pattern Lab Node needs to change to accept N number of UIs to build. This issue will attempt to capture what is needed for that to be successful.

I think an acceptable way to think of how this would work is to start at the configuration point and move forward from there.

Proposed Solution

patternlab-config.json

 "uikits": [
 {
   "name": "@pattern-lab/uikit-workshop",
   "outputDir": "workshop",
   "enabled": true,
   "excludedPatternStates": [],
   "excludedTags": []
 },
 {
   "name": "@pattern-lab/uikit-storefront",
   "outputDir": "storefront",
   "enabled": true,
   "excludedPatternStates": ["inprogress", "inreview"],
   "excludedTags": []
 },
]  

High-Level Pseudocode build()

1. Build source patterns
2. require() all uikits by name
3. For each uikit in uikits...
   1. Build frontend...
      1. bail if not enabled via config or maybe a runtime flag
      2. exclude patterns as indicated by state and tag exclusions in the config
      3. output to outputDir as root - join to paths.public
   2. Copy assets into frontend

From what I can think about it right now, uikit build could be parallelized. Not sure if it's worth doing that, but may be neat!

Questions

1. Would all uikits share the same _meta files? That would certainly be easiest, but may be limiting.

Evaluation

❌ index.js

• headPatternPromise and footPatternPromise decomposed but only used within ui_builder (a good thing from a refactoring standpoint)

❌ patternlab.js

• The assigment of templates hanging off of patternlabFiles assumes a single uikit

  • header
  • footer
  • patternSection
  • patternSectionSubType

• writePatternFiles() assumes a single uikit

❌ ui_builder.js

• assumes a single uikit
• needs to filter out states and tags not wanted to output

❌ exportData.js

• assumes a single uikit
• might be a good extension point for custom logic within a uikit. use events?

❌ copier.js

• assumes a single uikit

❌ pattern_graph.js

• exportToDot() assumes a single uikit

✔️ pattern_exporter.js

• assumes a single location - but I think that is okay

---

MISC

1. We need to well-document part of the UI-build process we have previously let slide if we want teams to adopt this approach (or even if we want to easily create uikit-storefront

   • the data schema available to a uikit at render time
   • the expected templates a uikit provides
   • the file locations Pattern Lab will output after build

2. We need to update Ecosystem documentation to refer to uikits and the ability to have N of them

3. It's probably revisting in meta patterns are truly optional. We try to fall back to general header and footer but I need to test if this works in practice.

[bradfrost]

@bmuenzenmeyer YES! I love the design of the config.

It's probably revisting in meta patterns are truly optional. We try to fall back to general header and footer but I need to test if this works in practice.

What do you mean by this?

[bmuenzenmeyer]

@bradfrost

ugh that was a terrible sentence on my part, sorry! I'll try to explain better, for my benefit too!

in my analysis of the code (looking for places where we assumed one ui only), it looks like Pattern Lab tries to use https://github.com/pattern-lab/patternlab-node/blob/master/packages/uikit-workshop/views/partials/general-header.mustache and https://github.com/pattern-lab/patternlab-node/blob/master/packages/uikit-workshop/views/partials/general-footer.mustache if the meta/ patterns do not exist - but honestly, I have never advocated for it, nor really tested to see if it worked!

So, this defensive code is either a misunderstanding of the original algorithm on my part, or a feature. Either way, making a decision as to what to do with multiple uikit support is important - because we could do the following:

• 1. EASIER: drop support for general-header and general-footer inside uikits - making meta/ patterns required and simplifying uikits. Make sure these not used anywhere else.
• 2. HARDER: maintain support for a general-header and general-footer - meaning they should be honored if present per uikit-build (unless a meta pattern exists for both).
• 3. HARDEST: do 2) but also support multiple meta patterns per uikit. Does a workshop pattern need different head or foot logic than a storefront pattern?

[bradfrost]

@bmuenzenmeyer Ah I see!

My opinion is that meta patterns — that is a <head> and a foot — should always exist. So I don't know if the general header and footer (if we keep them I'd recommend changing them to "head" and "foot" to avoid confusion) are necessary.

That said, I think it's important to support multiple head and foot instances. The workshop and the storefront are in essence two entirely different websites with different needs and requirements. So it's important to be able to link up certain libraries and stylesheets etc in the storefront view that the workshop view would never need.

So I think what I'm saying is some combination between option 1 and 3. Make meta patterns a requirement, kill general header and footer, and make it possible to have different meta patterns per uikit.

[bmuenzenmeyer]

Dropping this as a reminder to myself:

last bit of known work here is making incremental builds pick up changes and reload the page.

on feature/uikit-refactor-debug i make a change after gulp patternlab:serve

at one point the console output flipped from

rebuilding
reloading

to

reloading
rebuilding

after the initial run - but now a recent commit has changed the behavior.

next steps: investigate further. race condition? broken promise chain? live-server problem only?

off to easter 🐰