Consider changing base template system #69
Comments
|
My vote would be on vue, given the above options. I also am not opposed to keeping Hogan |
|
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. |
|
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 |
@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. |
|
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.
pattern-lab/patternlab-node#603
…On Sun, Sep 10, 2017, 7:27 AM Brad Frost ***@***.***> 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
<#69 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASNw9nrHtCzPAVE2e5zNirE7kayFgKYks5sg9XJgaJpZM4OzUr_>
.
|
Ok, sounds good. Might not happen for a couple weeks as I'm out for next week.
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.
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. |
|
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. |
perhaps react is in fact what is needed to best support #70 like I said before, eager to see where this goes! |
|
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. |
|
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:
Pattern frame:
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. |
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. |
|
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. |
correct @geoffp my perhaps complete list of frontend goals are:
|
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 drupal-pattern-lab/roadmap#8 (comment) include:
The text was updated successfully, but these errors were encountered: