pattern-lab
Symfonize all the things!
I'd like to propose refactoring Pattern Lab PHP to use Symfony components and best practices as much as possible.
Pros:
- Less custom code.
- Pattern Lab PHP already uses several Symfony components.
- Code is more approachable by people who know Symfony, making it easier to contribute.
- Same skills can also be used in other projects like Drupal and Drupal Console. Lots of synergy opportunities!
- Current static classes cause tight coupling and are bad for unit testing.
- Dependency injection and decoupling console commands from business logic could make all kinds of interesting things possible...
Cons:
- ?
Background:
The secret plan I mentioned in #150 was to replace Pattern Lab's console code with Symfony's Console component. My experiments with that have been very positive, but I quickly realized that a full rewrite using dependency injection and separation of concerns would be really nice. Or at least something I'd be very interested in and motivated to do! :)
Implementation plan:
We could add new Symfonized implementations of PL core code, with the old console commands using the old code and the new console commands using the new code. And when the time is right, we'd just leave out all the old code and release PL 3.0.
Tasks:
- [ ] Decouple editions from core #155
Was literally poking in the guts of PL this week looking to live-route requests instead of writing to the filesystem and was inching toward this direction.
@illepic I was literally doing the same thing last weekend! I came up with a POC giving PL the ability to render individual patterns via a tiny PHP server instance (aka let Node get PL rendered HTML if you pass the service a pattern name + data to pass in)... kind of like a mini Pattern Lab web service....
Will try to get code posted today or tomorrow!!
Get out of my head @sghoweri, this is MY EXACT USE CASE. Let me guess, you've Webpack'd pretty much everything and this is the last bit needed to get this output on the "dependency chain" of a component?
Guess where we're heading here: https://github.com/phase2/pattern-lab-starter/tree/epic/v10.
@illepic
Get out of my head @sghoweri, this is MY EXACT USE CASE. Let me guess, you've Webpack'd pretty much everything and this is the last bit needed to get this output on the "dependency chain" of a component?
Ding ding ding ding ding! Bingo. But that's not all.
The TLDR; version is that our Design System uses Lerna for versioning & publishing standalone components, ITCSS to organize and scale shared design tokens, mixins, etc, and Gulp + Webpack to glue everything together.
Unfortunately we just keep hitting more and more hurdles with the way Pattern Lab works and expects things... (and mind you, this is after coming up with around a dozen patches to help address some of these)
Just to name a few things I'm looking solve w/ this incremental / route-based rendering POC:
- Extremely long compile times when running Pattern Lab as a Design System monorepo (node_modules installed at the component level) since the PHP version of PL can't focus on just the patterns needed per request / incrementally.
- Extremely heavy (borderline unusable) Styleguide View All page
- Resolving the Webpack dependency chain / shared modules to optimize how things get bundled / chunked / asynced.
- Compiling test patterns to their own local dist folder for running regression tests (ie. better encapsulation) - similar to what we're already started doing w/ Webpack
- Schema validation + the ability to render patterns via a query string (inline editing similar to what Pattern Kit was doing)
- Decouple Styleguidekit Assets Default from PL core itself (major refactor, replace current Search, etc)
- Help w/ server-side rendering, especially considering the web component route we've been taking more recently
- Config patterns / define pattern variations in a single JavaScript file (cough Fractal cough)
So great that we are all thinking along the same lines! :)
Updated title accordingly and created first task/sub-issue.
Hey all! This all sounds fantastic, and while the technical details are well over my head, I just wanted to come in to simultaneously give a big 👍 and also a bit of a word of warning.
We want to make sure that PL continues to be an accessible and relatively lightweight tool in terms of dependencies. Based on what I'm hearing you all say, it sounds like this initiative is a bit of a behind-the-scenes refactoring to use Symfony's well-established conventions so there's less reinventing the wheel on PL's part. That all sounds great, and even better it helps address your specific project needs. So long as this is also useful for other PL users and it's done in an implementation-agnostic way, I'm all for it!
@bradfrost Thanks! This is indeed more of a behind-the-scenes type of thing, and everything should work as before for end users.
@aleksip @EvanLovely @illepic if you guys were curious, here's the working Patternlab PHP Renderer POC I've been working on with the main server logic just being a little under 30 lines of code:
https://github.com/sghoweri/patternlab-php-renderer/blob/feature/patternlab-server-poc/index.php
And on the client side (once a PHP Server is running), you can have Node ping that server with the Pattern + Data and if everything is working, it'll respond with the rendered HTML: https://github.com/sghoweri/patternlab-php-renderer/blob/feature/patternlab-server-poc/render.js
Still lots to do (especially w/ documenting all this + pointing out the small patch I had to add) but all in all this seems really promising!!
Hoping to try to get the iFrame viewer in PL wired up to this as a logical next step!