search

pattern-lab / styleguidekit-assets-default

The static assets for the default StyleguideKit for Pattern Lab. Contains styles and mark-up for Pattern Lab's front-end.
http://patternlab.io/
MIT License
35 stars 67 forks source link

Consider changing base template system #69

Open bmuenzenmeyer opened 7 years ago

bmuenzenmeyer commented 7 years ago

There seems to be some appetite for changing the frontend template language, but more research must be done. Currently they are Hogan templates, which are fast, approachable, and relatively simple.

Some contenders mentioned in https://github.com/drupal-pattern-lab/roadmap/issues/8#issuecomment-321026756 include:

bmuenzenmeyer commented 7 years ago

My vote would be on vue, given the above options. I also am not opposed to keeping Hogan

bradfrost commented 7 years ago

Per our conversation yesterday with @EvanLovely, I'm open to modernizing these templates, although I'd need a bit of guidance for setting anything new up.

EvanLovely commented 7 years ago

Several months ago I dug into this, started from scratch and built a MVP with React that works. No styles at all, but functional. Where should I commit this? A branch here? Or another styleguidekit? My original name was going to be styleguidekit-alt.

bradfrost commented 7 years ago

Where should I commit this? A branch here?

@EvanLovely yeah maybe put it on a branch here and then we can go from there. By the time we're ready to merge I will have hopefully tightened up the syntax and style.

bmuenzenmeyer commented 7 years ago

I'd like to see this too. The beauty of the current templates is their simplicity.

Do you think moving the default frontend to react, with all the tooling required, maintains the approachability for new users or users that want to tweak a template?

A goal of mine has been to make front end customization easier without having to fork and replace this repo.

https://github.com/pattern-lab/patternlab-node/issues/603

On Sun, Sep 10, 2017, 7:27 AM Brad Frost notifications@github.com wrote:

Where should I commit this? A branch here?

@EvanLovely https://github.com/evanlovely yeah maybe put it on a branch here and then we can go from there. By the time we're ready to merge I will have hopefully tightened up the syntax and style.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pattern-lab/styleguidekit-assets-default/issues/69#issuecomment-328339504, or mute the thread https://github.com/notifications/unsubscribe-auth/AASNw9nrHtCzPAVE2e5zNirE7kayFgKYks5sg9XJgaJpZM4OzUr_ .

EvanLovely commented 7 years ago

maybe put it on a branch here and then we can go from there.

Ok, sounds good. Might not happen for a couple weeks as I'm out for next week.

The beauty of the current templates is their simplicity. Do you think moving the default frontend to react, with all the tooling required, maintains the approachability for new users or users that want to tweak a template?

Once tooling is set up, a contributor tweaking an existing template doesn't need to worry about the build process as it's already been set up. We just need to consider when they open a template that it makes sense, so that's just how it's set up and that's something to consider in any templating language.

The big thing I want out of a new templating system for this is the the ability to re-render the component based on user interaction without a page reload. So if they are looking at a button and they click a checkbox for "Primary button?", then the button changes from the default to primary (i.e. gray to blue). The best way to do that IMHO is with something like React.

A goal of mine has been to make front end customization easier without having to fork and replace this repo.

Agreed, but probably too much for now I think. Maybe place that in a roadmap for two major versions from now?

bmuenzenmeyer commented 7 years ago

Agreed, but probably too much for now I think. Maybe place that in a roadmap for two major versions from now?

This has been a user concern for too long, and is on my short to mid term radar. I have a node plugin that achieves some of this, but it wouldn't take much at all to allow users to specify their own templates to override the current system. With so much else in flux in this repo, I think it prudent to hold off a bit, but I want to ensure we are meeting our users where they expect us too. The fact of the matter is that forking this repo and replacing it with a custom one is just too great a burden for many.

geoffp commented 7 years ago

Having used React and all the associated tooling for the past year, I'd rather use something simpler that exposes us to less code & tooling bloat, but still gets us a modern component architecture.

I admit to not having studied Vue extensively, but that's my current best guess of what would be ideal.

bmuenzenmeyer commented 7 years ago

The big thing I want out of a new templating system for this is the the ability to re-render the component based on user interaction without a page reload. So if they are looking at a button and they click a checkbox for "Primary button?", then the button changes from the default to primary (i.e. gray to blue). The best way to do that IMHO is with something like React.

perhaps react is in fact what is needed to best support https://github.com/pattern-lab/styleguidekit-assets-default/issues/70

like I said before, eager to see where this goes!

bradfrost commented 7 years ago

I've been looking at Vue for a while and I like what I see. The syntax feels like something even I can get my head around.

geoffp commented 7 years ago

FWIW, I think Evan's goal of no-page-refresh is a good one in principle, but we're still planning on loading patterns in an iframe, right? I don't relish the thought of that, but to me that still seems like that only way to cleanly render, in isolation, any template/component framework that we support. If we're going to push forward with the React engine (I know, I know, it's been forever) and similar, like Vue component support, Ember, nunjucks, yada yada, then it seems pretty hairy to try and support all those in the main UI, which I suppose we'd have to do if there were no iframe.

So I think the architecture, as I understand it, is roughly this:

Main chrome / navigation / search:

This I think accounts for both the development of static-y style guide pattern libraries, and super "live" front-end components that will react to user input without reloading the iframe. It's possible that shadow DOM might provide us with the kind of isolation we need from the iframe, but I'm not sure we can rely on that yet.

As always, I'm just thinking out loud here, and totally open to ideas. Apologies if I'm misinterpreting anyone's stated goals.

bradfrost commented 7 years ago

but we're still planning on loading patterns in an iframe, right?

Yep. The principle of Pattern Lab has always been that the tool doesn't impose anything on your code. Everything inside the PL iframe is the users, and everything outside is Pattern Lab's.

That said, there sometimes needs to be some communication between the PL layer and what's going on inside the iframe. @dmolsen created some listeners that allowed for that communication to happen. It would be great if that continues to be the way things operate, and @geoffp to your point we'd want to make sure there's no stepping on toes between PL's toolchain and whatever tools people choose to use in their dev environments.

geoffp commented 7 years ago

So therefore, I think if I understand @EvanLovely's desire correctly, he wants to do exactly what we did here with Pattern Lab: develop rich, interactive front-end components for use in a single-page app (or prog web app, or just-a-bunch-of-compnents with SSR, or whatever). We did this with Handlebars, loose JS, and SASS, so I know we don't need something like React to do that. In fact, I think that's all up to what the user, and I guess to a certain extent, the engine or edition, puts in the iframe.

What we lacked was an orderly way of introducing pattern-specific JS into the pattern frame. We hacked this together with a big ugly monolithic JS file that included JS for literally every pattern, surrounded by big ugly if statements. Obviously this file never made it anywhere near production, but it was necessary. This is a non-issue for JS-centric components like React and Vue, but it will remain an issue for developing rich components using templates + JS.

Okay, this is now very off-topic for this issue. Somebody stop me if I'm wrong, but the main point I think is this: that our choice of framework for the UI doesn't really affect what users can create with PL in the pattern frame. At least as long as, like @bradfrost says, we don't let our toolchain "leak" into the frame.

bmuenzenmeyer commented 7 years ago

that our choice of framework for the UI doesn't really affect what users can create with PL in the pattern frame.

correct @geoffp

my perhaps complete list of frontend goals are: