search

kaj / ructe

Rust Compiled Templates with static-file handling
https://crates.io/crates/ructe
445 stars 35 forks source link

Template partials/fragments #128

Open wrapperup opened 1 year ago

wrapperup commented 1 year ago

Hi, I've been toying around with ructe and htmx (it's great!), and one feature that would be great to see is the ability to render a fragment or part of a template. This is great in the context of htmx, where you re-render a small part of a template. Some reading: https://htmx.org/essays/template-fragments/

Prior art:

  1. https://github.com/sponsfreixes/jinja2-fragments
  2. Minijinja just merged this feature in https://github.com/mitsuhiko/minijinja/issues/260,

My quick sketch is something like

@(param: Type, ...)

<body>
    @fragment name(param: Type, ...) {
        <p>Hello @param!</p>
    }
</body>

Since parameters are defined in the template, it probably(?) makes sense that it must be a subset of the parameters in the main template. A new module would be created with the parent template's name and the name of the fragment I'd imagine.

kaj commented 1 year ago

What is the point of having a template fragment rather than a small separate template? In a more "dynamic" template language like jinja, I think the benefit of template fragments is not having to handle a lot of separate templates, as each template are loaded and parsed in run-time. But in ructe, the templates are all compiled, so there is no such loading / parsing overhead, and no problem with having a large number of templates. Or so I think?

wrapperup commented 1 year ago

It's more of a convenience thing. With libraries like htmx, it's nice to not have to split out things into seperate files, and the author talks a lot about locality of behavior. It's definitely not a necessary feature, but it would be nice.

In terms of performance: I haven't run the numbers with Minijinja, but I suspect the cost of lookup is pretty insignificant compared to the VM eval step, at least after all the templates are cached and compiled. It probably would be faster to render it as a completely seperate template in that case, since you get to skip the overhead of evaluating parents and evaluating the top-level template.