-
Notifications
You must be signed in to change notification settings - Fork 276
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
Extract template language and data gathering #10
Comments
I could see the benefit to using another template engine, but what other types of data gatherers would you envision being useful? My initial feeling is that if you need something THAT custom, you could just write a custom node script that would do the job. |
Perhaps you're right. Honestly the only use case I had when I initially thought of this was when plop didn't support partials and I wanted to add one, there was no way to do this. Now that it supports that I don't have a use case for this capability. At the same time I could definitely see that some people may wish to utilize plop with a different template engine. As for the data gathering tool, there are others, but inquirer is pretty good and I certainly don't see a reason to use anything else. The other thing is there's a great benefit to making tools pluggable so others could develop plop plugins themselves (freeing up your personal time which I'm sure you're beginning to notice is slipping slowly away) :-) Also, thanks for pushing back :-) PDD |
yeah, I've tried to do that a little recently with custom action functions which really open up a lot of possibilities for the JS guru. It would be nice to have an extension point on the input side too, but I think maybe an inquirer addPrompt function may fit the bill. I like the idea of making things pluggable, but I also want to keep things simple for the 90% case. |
Personally I think that it can be pluggable and simple(r) but it's your project (and thank you for it!) |
possibly, if you think of a simple way to do it let me know. I guess I'm not really sure what benefit it would provide. inquirer and handlebars are both pretty pluggable, so I'm not sure what else you might need. I'm sure there are things I'm just not thinking of. |
Two year old issue, but I'll jump in anyway. I was gonna create a separate issue, but this seems relevant. I wanted to ask if you ever considered moving away from Handlebars into something like EJS? Handlebars' built-in plug-ins are so limited it makes my template code so messy. I'd rather not have to create a custom plugin just to compare 2 values or to do an This change would totally not be backwards compatible and switching over would probably be problematic given how different the templating approaches are, but if the templating part was pluggable as @kentcdodds was suggesting, then it could be a win-win? What do ya think? |
I'll give it some thought. I wouldn't be opposed to creating a path where someone could plug in a different template engine, but I would probably want to keep Handlebars as the default for simplicity. There might be a way to provide hooks to basically bypass Handlebars and pipe the template data into another system... 🤔 |
Yeah I think it's wise to keep Handlebars as a default. In trying to get passed Handlebars' limitations a did a lot of code spelunking in Thanks! |
@benmvp that would be great. I'm thinking that we might be able to add a plop api method that would register a function to take over template rendering (something like Thoughts? |
Another possibility would be to simply add a lifecycle hook that would execute prior to template rendering. Handlebars could still process the result, but if there's nothing for handlebars to do, then the data would simply pass through. |
Yep the What's the advantage of having Handlebars process after the lifecycle hook? I'm not seeing the use-case where you'd want double processing. Is it just the limit the scope of the change of supporting a different renderer? |
My thought was that there might be a desire to use EJS without breaking existing Handlebar generators. By keeping the handlebar processing, a plopfile could be migrated to a new rendering engine over time. Maybe the ideal setup is one that allows the rendering engine method to be a config attribute on the setGenerator() object, rather than forcing it to be set globally for the whole plopfile. hmmm... |
Good point. We don't want it as easy as possible for folks to migrate over. Having it as a config property on I would be annoying though if you're starting fresh (like I was 2 weeks ago), and you had to specify EJS for each generator. Maybe the answer is a global setting for the whole plopfile with the ability to override on the generator level? So if you wanted EJS for everything, the plopfile could just define that. But if you've got existing stuff, you can go in one by one for each generator. Does that work? |
I wonder if a more generic way to set defaults might be the way to go. We could use something like |
yep that makes sense! |
I'll put together an updated API draft + a high-level spec of the necessary changes here and in |
Ok, sorry for the delay. Got back from break this week and was able to start thinking through the API. It looks like the entirety of the API is in This is just an initial stab at it, so I'd love your feedback. Let me know if you think there's a better environment to work through this
|
@amwmedia any thoughts on this? |
@benmvp sorry for the delay, I'm ready over this and will respond soon. |
ok, I think I have an idea of how we can do this and introduce a little less mental overhead. New
|
I think this looks good! I'm assuming if you don't specify I really like passing in So rewriting my sample plopfile from above would look like: import ejs from 'ejs';
export default (plop) => {
plop.setTemplateRenderer('ejs', (template, data, plop) => {
// need to build object lookup of helpers to pass to ejs.render()
const helperList = plop.getHelperList();
const helpers = helperList.reduce((helpersLookup, helperName) => {
helpersLookup[helperName] = plop.getHelper(helperName);
}, {})
// NOTE: no need for partials because EJS handles those w/ includes
return ejs.render(
template,
Object.assign({}, helpers, data),
{debug: true}
)
});
plop.setGenerator('name', {
templateRenderer: 'ejs',
description: 'A generator based on EJS',
prompts: {
},
actions: {
}
});
// -or-
plop.setGenerator('name', {
description: 'A generator based on the default Handlebars',
prompts: {
},
actions: {
}
});
} The only thing funky is the |
yeah, I could see these |
your modified example looks good, but (in reality) the eventual usage would probably look more like... export default (plop) => {
plop.load('plop-ejs');
plop.setGenerator('name', {
templateRenderer: 'ejs',
description: 'A generator based on EJS',
prompts: [],
actions: []
});
// -or-
plop.setGenerator('name', {
// default templateRenderer: 'handlebars',
description: 'A generator based on the default Handlebars',
prompts: [],
actions: []
});
} |
Ahhh... I see. Hadn't really investigated export default function (plop) {
plop.setTemplateRenderer('ejs', (template, data, plop) => {
// need to build object lookup of helpers to pass to ejs.render()
const helperList = plop.getHelperList();
const helpers = helperList.reduce((helpersLookup, helperName) => {
helpersLookup[helperName] = plop.getHelper(helperName);
}, {})
// NOTE: no need for partials because EJS handles those w/ includes
return ejs.render(
template,
Object.assign({}, helpers, data),
{debug: true}
)
});
}; ? |
I think we've got the API in a solid place, so I'll start dev on it. |
great, thanks! |
Hey @amwmedia! So we missed one big part of this and that's I'm thinking we can update it to take an optional third Does that sound about right? |
@benmvp hmmmm, I'll look into this in more detail today. I actually had a moment there where something inside me said "that was almost... too easy". 😐 |
Looks like we both forgot about this 😉 |
it's still on "my list" but unfortunately, my calendar blew up at work and home so I haven't been able to find much time. I suppose we would need to handle this the same way as we would for the generators. Like you say, we could accept a 3rd (optional) param that would be the |
👍 I'll just try to put something together and we can work from there |
If you need any help I am willing to help with the change. Now I see that it is duplicate and I really want to introduce this change. |
I'm in favor of you taking it over @marcelmokos! |
Any news about using ejs? |
I started using hygen. Thank you |
@benmvp have you ended up starting work on this? If so, is there a place we could look at the changes that were made to get things started on it? |
Nope I didn't. I needed some help from @amwmedia but after the delays just moved on. I don't really remember any of the details 2 years later. Still think it's a good idea so have at it! |
No worries, I just wanted to check. I'll see what I can do about implementing this in the coming months |
That's what I said 😂 |
I think that it'd make this utility more powerful if both inquirer and handlebars integration were extracted to plugins to make this utility pluggable. That would allow me to provide my own template compiler and data gatherer. It would also allow for customizing these things without having to make plop expose APIs for these things explicitly. Thoughts?
The text was updated successfully, but these errors were encountered: