Dynamic templateFile

[plopjs]

Dynamic templateFile

[amwmedia]

I think it's probably best to process that value as a template for consistency sake

[nicoespeon]

I guess this should work 🤔

It sounds reasonable. I'll give it a try when I've got some free time.

[amwmedia]

that's correct, currently the templateFile is not processed by handlebars. I see now from your example how this could be helpful. Currently the way you would do this is by making the actions array a function that returns an array. This is explained in the README under using an actions function. I'll probably be renaming this soon, but that's how you could solve this today.

[inyono]

Cool, thanks for the answer 👍 Feel free to close this issue if it isn't relevant to you.

[amwmedia]

if others see benefit to making templateFile a handlebars template, I'll consider doing that. My main reason for not doing it thus far is that it opens the generator up to lots of possible poor configurations. For instance if someone wrote a generator that used free text input from the user to construct the path, it would be pretty brittle. I'll give it some more consideration.

[miklosme]

I wrote this generator first:

    plop.setGenerator('Dashboard widget', {
        description: 'Creates a dashboard widget',
        prompts: [{
            type: 'input',
            name: 'name',
            message: 'What is the name of the widget?',
            validate(value) {
                if ((/.+(w|W)idget$/).test(value)) { return true; }
                return 'a widget must end with `Widget`';
            }
        }, {
            type: 'list',
            name: 'kind',
            message: 'What kind of widget do you want to create?',
            choices: ['LineChart', 'BarChart', 'TinyCard'],
        }],
        actions() {
            return [{
                type: 'add',
                path: 'src/app/core/components/dashboard/widgets/{{dashCase name}}.jsx',
                templateFile: 'config/plop/templates/dashboard/{{dashCase kind}}-widget.jsx.txt'
            }];
        }
    });

Then I rewrote it to this:

        actions(data) {
            const widget = plop.renderString('{{dashCase kind}}-widget', data);
            return [
                {
                    type: 'add',
                    path: 'src/app/core/components/dashboard/widgets/{{dashCase name}}.jsx',
                    templateFile: `config/plop/templates/dashboard/${widget}.jsx.txt`,
                },
            ];
        },

So not a big deal, only lost a few minutes on it, but I would expect the upper one to be correct.

By the way, great library, thank you!

[amwmedia]

hmm, interesting point. I may add this in. Hadn't really thought of the use case where you have 3 files that all take the same object interface and a controlled way to switch between them with a prompt. 👍

[nicoespeon]

I do understand too that the upper example was expected.
Plus, this is something that can be achieved anyway with the plop.renderString() method.

So either we don't want to "make it easy" to avoid "poor configurations" ; either we should parse templateFile through handlebars.

IMHO, as I said, I'd probably have expected templateFile to deal with handlebars variables, if I needed to.

@amwmedia > Any reluctance to do that? Or can I tap into it?

[nicoespeon]

Unfortunately, there is one regression we didn't thought about.

Let's say you named your template my-name-is-{{dashCase name}}.txt. With current implementation, this will parse the file name to use the variable you passed in to customize your file name (e.g: my-name-is-john-doe.txt).

If we do parse templateFile on the other side, then this won't work anymore − it will search for a my-name-is-john-doe.txt template, which doesn't exist.

What's your opinion on this? 🤔

[amwmedia]

pondering... 🤔

[nicoespeon]

From my point of view, I think both features could be useful. But they are conflicting.

But if we take care of both, we might complicate the API. I don't think this is a good idea. Or maybe there is a simple way to do that?

If we have to choose, then I'd say that having the template file name variable is handy and expected (template file and its content are parsed). Being able to dynamically choose the template file however, this could be done with an action function, as demonstrated.

Sure, looking at the code, I'd have expected the templateFile to be parsed. But I didn't thought about the conflict. Maybe we should explain that explicitly?

[miklosme]

As an alternative, you could just describe the situation when the lib can't find a template file with /{{(.+)}}/ in it.

[amwmedia]

using a templateFile with a template string in the path is currently only used for addMany because in the add action you specify the full path to the template separate from the full path to the destination file. So we could conceivably tweak the add action to handle the templateFile as a template, while the addMany action uses globs to find templates. I'm still not 100% sold on this just due to the inconsistency, but it would be possible.

Another possible option would be to make the templateFile attribute accept a function that would be executed with the answers as a param. That would give the flexibility to dynamically change the path, but not interrupt the existing api.

Thoughts? Other ideas?

[nicoespeon]

I think you can already change the path dynamically without interrupting the API, using the actions function as @miklosme did. So I don't think it's necessary to make templateFile accept a function.

You're right too: template string in the path of template files is only used for addMany. So that would mean we could make it work for the add and modify actions, but not for the addMany.

I feel that would be acceptable if we do document this for the addMany action − along with the sentence that explains that template files/folders can use handlebars syntax here. I don't have any better solution in mind that wouldn't complicate the API.

[amwmedia]

We might actually be able to make it work for addMany as well if we call renderString() before we pass the path value to globby. That way you have the ability to use templating in the actual templateFile property AND the rendered destination could still use the template data in the file name.

If someone really wanted to name a template file with {{template}} stuff inside, and still reference the file directly, it would be possible by escaping the template blocks with a backslash.

example: \{{dashCase name}}

Thoughts?

[amwmedia]

added in plop v1.9.0