Dynamic component assignment through attribute about marko HOT 3 CLOSED

Hi @bkniffler, a custom tag is just a mapping to a render(input, out) function that gets resolved at compile time. It's possible to invoke a render function directly instead of going through a custom tag and I think that might help in your case. This is done using the <invoke> tag as shown below:

<!-- Loop over components, each which as a render function and an input model -->
<div for="item in data.components">
   <!-- Invoke the render function for the current item using the current item's input model -->
    <invoke function="item.render(item.value, out)"/>
</div>

NOTE: A loaded template also has a template.render(input, out) function so you could also do the following:

<invoke function="item.template.render(item.value, out)"/>

I'm not sure if you are using the RaptorJS Optimizer or Browserify, but the RaptorJS Optimizer supports dynamic requires while Browserify does not. Therefore, if you are using the RaptorJS Optimizer then you can send down all of the templates that may be needed on the client and dynamically require them instead of relying only on static code analysis. You can use a glob pattern to send down all of the templates in a directory as shown below:

optimizer.json

{
    "dependencies": [
        "*.marko"
    ]
}

Those templates could be dynamically required doing something similar to the following:

var template = require('marko').load(require.resolve('./components/' + componentName + '/template.marko'));

NOTE: We currently don't register the *.marko.html extension for the optimizer-marko plugin so you might need to send a PR for the plugin.

Does this help in your use case? If not, please provide more details.

from marko.

@bkniffler I would recommend an approach that uses a single component/tag that simply delegates rendering to multiple other components/renderers.

For example, I often run into the use case of choosing a template based on a type or layout attribute. Consider the case where you might want to do something like this:

<app-message type="info">${data.message}</app-message>
<app-message type="warning">${data.message}</app-message>
<app-message type="error">${data.message}</app-message>

Depending on your use case, this might be simpler than having three separate tags (app-info-message, app-warning-message, and app-error-message, for example).

In this example, app-message may have a template for each type of message. The app-message renderer would simply choose the right template based on the type.

The app-message component would have a renderer.js with something like this:

var marko = require('marko');

var TEMPLATE_BY_TYPE = {
    info: marko.load(require.resolve('./info.marko')),
    warning: marko.load(require.resolve('./warning.marko')),
    error: marko.load(require.resolve('./error.marko'))
};

module.exports = function(input, out) {
    // find the template that maps to the given type
    var template = TEMPLATE_BY_TYPE[input.type];
    if (!template) {
        throw new Error('Invalid type "' + input.type + '".');
    }

    // now render the template
    template.render(input, out);
}

In summary, I think this logic of choosing a template would be easier to read if the developer moved this logic to the renderer. I don't think there would be much benefit of implementing this "choosing" logic in the template.

Please let me know if you still don't think the solution from @patrick-steele-idem or myself would help in your use case (or if you are still looking for a more elegant solution).

from marko.

@philidem This is a nice approach, unfortunately not what I'm looking for.

Thanks to both of you for taking the time to respond in such detail., this helped me understand marko more. And sorry for apparently not explaining my issue properly, when re-reading the docs I found a great solution already in place: the include-tag. It seems to do all the required stuff like loading and rendering.

<include template="app/components/$!{item.component}/template.marko.html" value="$!{item.value}">

This will help me get started for now!

I will add .marko.html support to optimizer-marko in the next days.

from marko.