-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PatternEngines ongoing work, round 4 #208
PatternEngines ongoing work, round 4 #208
Conversation
Fix wrong class name for Error Input
…vated privileges - THX: Thanks @RichardBray for the heads up - ADD: Added a Prerequisites section to the README
real plugin files rather than a hard-coded list. Also, better organize the PatternEngine setup functions to be cleaner, more functional and more testable
added unit test for pseudopattern generation fixed a bug where pseudopatterns were being added to the UI twice explicitly sorted patterns before UI build setting version to v0.16.0
more functional, which seems nice for unit tests; incorporate @sghoweri's fix to the pattern_assembler
file-based unit testing
SHAME. "hello worlds" promoted to molecule!
Unit test to cover this Resolves pattern-lab#171 Marking this version 1.0.0 - having achieved broad feature parity with PL PHP v1
if (config.debug) { | ||
console.log('==================== FOUND NON-MUSTACHE FILE'); | ||
} | ||
return; | ||
return currentPattern; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a super great idea. 💯
Right. As we've said before, the more unit tests we write this way vs total faking, the better. But I cringe when I force myself to do this and therefore am eager to spend more time making the whole product more unit testable. |
Agreed on both accounts
Right. A primary concern, handed down from Dave and Brad at the onset, was to keep Pattern Lab approachable. Now would could argue node, grunt, gulp etc are already skirting that line, but pattern engines to me are advanced functionality. That's a long-winded way of saying to the extent possible I'd like to us to ship with only mustache, and provide thorough documentation as to how to add another engine if someone wishes to use one. I haven't thought through what that means for our Travis CI builds; but my goal would be to always execute all tests. |
@geoffp Let me know when you feel this is ready for another merge. I love how this is maturing. I did a quick scan of the commits, but have not run this yet. |
My 2 cents re: pattern engines and defaults since my name was invoked... I'm not sure if you can roll PL Node this way or if it would hinder testing but I'm trying to use "editions" as my way of organizing pattern engine-specific versions PL PHP. So the PL PHP default repo will use the Mustache pattern engine but we also have a PL PHP Twig repo. The standard for the repo names should give you the flexibility to add your own node editions if you like. eg. That said, I think the reality is that we need to embrace package managers as it's the only way to get maintainable and customizable code/features. Not everything we do can be "core" and upgrades can't be copy & paste. From a PHP perspective this has meant rolling the bulk of PL into it's own package but hopefully it's worth it long-term. The projects just naturally have to get "a little more complicated." I definitely think that's ok. |
I'm glad you mentioned that, Dave, I don't think I'd realized that about the PL/PHP architecture. It does seem like providing pre-built "editions" for each engine type, with the template renderer's npm dependencies pre-installed, is a superior first-setup experience. But: does the PHP version support more than one engine per pattern tree? Can you have a "mixed" tree if you need it? My team does have a need (at least we think we do) for a mixed pattern tree, at least in the short term. Of course, that requirement comes with some questions:
It seems like there are at least these three roads we could go down:
I lean towards attempting the #2 solution as a default, and then at least try to assess the plausibility of #3. |
@bmuenzenmeyer got v1.0.0 merged! |
@geoffp As things currently stand (at least with the Twig work I've been chipping away at), your 2nd solution is how things are setup out of the box. The way templating engines like Twig work out of the box, any partials getting referenced within that particular template must be of the same type. Everything remains separate by template type, however it all still gets compiled, registered and presented in the same interface within Patternlab. IMO, the best approach might be to take a page out of the PL2 for PHP project(s) and begin to think about how we might be able to decouple and separate a few of the different moving parts that exist within Patternlab for Node. For example, the following could be split out into separate repos which can then be installed, updated, mixed and matched and customized individually via NPM.
FWIW, I've been working with PL2 for Twig for about 6+ months now on two huge projects and really do love the decoupled strategy Dave has been working on. I'd love to see what we can do to come up with a similar strategy for the Node version of Patternlab as well. |
Building on @sghoweri's notes. I think adding Two historical notes on the set-up of PL2 PHP in case it helps you all. the components of a project. more details the on components. @bmuenzenmeyer - time to revisit the spec? |
@geoffp - Clarification - based on the config one pattern engine is registered as the Renderer of Patterns at start-up. So then when I call something like |
So, okay, this all makes sense. I'm super on board with @dmolsen's decoupled component architecture. There has to at least be a way to upgrade or swap out the moving parts without disturbing your actual library of patterns. Even though this complicates the architecture, I think Salem and Dave are right that NPM can make it pretty easy. In the present-day monolithic world, my approach has been to include all supported engines, but only enable the ones whose renderer is installed by the end user. Even in that architecture, if we want to deliver easy-peasy starter kits like PL/Node+Handlebars or whatever, in the short term, it's just a matter of packaging and what's in the package.json by default. But if pattern engines were factored out into their own npm packages, dependencies would come along for free. And no matter what starter kit you use, you can always just install another engine if you need a mixed tree. That seems cleaner. As we were talking about splitting all these parts into npm modules, I started to get anxious about the awkwardness of git workflow when working on an npm module in-place, but I found npm link and now I think I feel better. |
@geoffp -
|
Wow this is a lot to digest in such short time!I want to try to address this all in an organized, methodical fashion. Modularization of Pattern Lab NodeA lot of ideas are coalescing around making Pattern Lab more modular, like PL PHP is doing. I definitely see npm playing a big role, and perhaps git submodules?, which I know little about.
I definitely plan to work with you all on this. No need to have duplicate versions of these things if at all possible.
This. This is the overall goal of this issue, which has been on the backlog for a while. From the history, you can see I put it off a number of times, and now the chickens come home to roost! 🐔 Every time I have to ask someone to copy/paste or alter a file manually during an upgrade, I feel like I've let them down. In some alternate reality I envisioned doing this before I embarked on pattern engines. I think not having a better separation of concerns naturally causes pattern engines discussions to include this topic, complicating both. More on how to unwind this knot in a bit... Pattern Engines & Balance
I'd like to further pursue this mindset. I never imagined we'd be shipping with mustache, handlebars, and twig engines. That's doing a disservice to anyone installing. I think everyone agrees there is a better way.
I've held very tight to the notion that Pattern Lab should be approachable. It was one of the tenants Brad spelled out early on with my involvement. I've been wrestling with the degree to which this is attainable, as tooling like grunt, gulp, BrowserSync, npm and such get injected more and more into our conversations. It's clear we are all advanced enough users, but what of the silent majority that just need it to work?
I think that whatever shape the PL Node architecture takes, we should keep this directive in mind (until otherwise known). Next Steps?To me, a possible course of action looks like:
Cheers. |
I think there is and has to be a continuum regarding approachability. Kind of like progressive enhancement. Someone will be able to install PL PHP from a pre-built zipped package or via Composer, PHP's package manager. Having a similar approach for your version of the project might be a way forward for you to balance managing complexity with Brad's original mission. Regarding "editions"... this may be something that is more suited to PHP/Composer than Node/NPM so please don't feel tied to it. Composer has a nice create-project command that projects set-up like PL tend to use. I'm not sure NPM has a similar command. |
Heyo, @dmolsen mentioned "Brad's original mission", which might need a little clarification. A lot of my beef with a lot of tools and software out there is that the barrier of entry is way too high, dependencies are a never-ending rabbit hole, and documentation is full of language like "just do blah blah blah". So when we made Pattern Lab, there was a lot of effort put into keeping the requirements, overhead, and arrogance to a minimum. I'm thrilled Dave has done a great job of keeping that in mind over time, despite the software becoming more complex. I'd very much love it if the new version of PHP Pattern Lab and the Node version continue to be tools people can spin up and get their heads around very quickly, yet still follow current best practices for real-world development. I'd be so bold as to say this is especially important to get right with the Node version. In my own Node journey, I find documentation for almost every tool & package to be chock full of arrogance, overhead, and assumptions. It would be so great to see Pattern Lab Node as a very approachable tool that doesn't require a master's degree to get off the ground. I'm not the one to suggest specific solutions on how to accomplish that, but I think that's a goal worth pursuing. I feel like the whole ZIP concept Dave mentioned really achieves this balance between simplicity and robustness. A user can download a ZIP of a certain flavor of the project, run a command, and be up and running. Hooray! But if a sophisticated user is familiar with package managers, etc, they can opt to do the Real Deal environment set up that gives them a lot more power. I love how Dave called it a progressive enhancement of sorts. Anyways, that's my two cents. |
Thanks Brad - I think we can stay the course with focused effort, and would always appreciate any feedback on the Node documentation as it evolves, both here and on patternlab.io |
On approachability, long/medium term: So, we're experimenting with PL as a compositional tool for designers that have (or want) HTML+CSS skills. Off the top of my head, I can tell you that what's been not-so-approachable about that so far hasn't been PL internals or what's in the package.json, it's setting up the git + nodejs + npm + grunt toolchain on their laptops, and teaching them about those tools and the command line. It's a lot to take in for non-developers. Feel free to say that those users aren't PL's main target audience -- I would certainly accept that -- but for those kinds of users, my feeling is that the experience wants to be as close to this as we can get:
On next steps: @bmuenzenmeyer I like your proposed roadmap. |
The target audience has always been as wide as possible. The Node version is a bit more inherently advanced-entry... since it leans so heavily on these task runners. PL PHP is more approachable IMO, with its shipped command files (I think Mac only...) But that doesn't mean we can't do better!
This issue exists to handle this better. I agree it'd be nice - it's just never been prioritized high against working on other things. Probably wouldn't take too long to create a couple different files users could click on to start. Getting this on the roadmap is important. I'll put some meat on its bones soon and tag it up for grabs if someone wants to tackle it. Also: updated the roadmap to somewhat reflect all this discussion. Will continue to grow it out as needed. |
It kills me that Apple no longer supports the |
@dmolsen Maybe it would work to create a super thin AppleScript for Mac, PowerShell for Windows, and .desktop file for Linux that do nothing but launch the "real" shell scripts. |
problem now with patternlab.json having cyclical references that needs to be fixed.
the Handlebars engine was in use.
Hey guys, sorry for the lull! I had the simplest problem holding me up: I was trying to render our library of Handlebars templates, and the log file, The solution I landed on was to pass a custom replacer function to There's also a new optional engine method, |
And hey, @bmuenzenmeyer, thanks for the shout-out on the MS Dev Show! That was fun to hear. It got passed around at Target. |
@geoffp you bet on the shoutout - It's eternally cool that you guys even deem it worthwhile, and are actively investing in it. It's means the world to me, really. When the dust settles a bit I'd love to learn more about what you guys are building - or if you could share some screen shots with me via DM or email, would be great! Sorry bout patternlab.json - it's been growing bigger and bigger over time, and was WAY more manageable and useful during early dev. Still, nice to see raw state sometimes. I've been meaning to try out something like Webstorm that actually lets me debug a bit easier. Per some conversations with Dave - I am hoping you and Salem can get engines relatively stable, and then I'll likely embark on a solitary crusade to restructure. I think it might be easier if one person does it. I'll likely need help/info from you two along the way. |
Yeah, I've had some pretty bad times working with more than one person while moving lots of files and dirs around. Or even fixing widespread indentation issues. The merges are horrible unless you flip just the right switches. We should do a Google Hangout or whatever sometime soon, if you're game (and if that's permitted on our network) and we'll show you what we do! I'm sure anyone in this thread who's interested would be welcome to join. I think this is ready for merge now. @sghoweri, how's your branch? I'd love to get that work in here. |
@geoffp can you test out adding pattern-engines to the branches list inside https://github.com/pattern-lab/patternlab-node/blob/master/.travis.yml I want to see if it will kick off Travis builds |
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
PatternEngines ongoing work, round 4
Here's the first cut of a working Handlebars plugin, plus a file-based unit test (@bmuenzenmeyer: doing it right?). It's just enough right now to prove that we can render a "hello world" atom and a "hello worlds" molecule that includes it twice as a partial.
Highlights:
TODO: