Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Template partials/fragments #128

Open
wrapperup opened this issue Jun 19, 2023 · 2 comments
Open

Template partials/fragments #128

wrapperup opened this issue Jun 19, 2023 · 2 comments

Comments

@wrapperup
Copy link

wrapperup commented Jun 19, 2023 •
edited

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 Feature: Render Block fragment mitsuhiko/minijinja#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
Copy link
Owner

kaj commented Jun 22, 2023

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
Copy link
Author

wrapperup commented Jun 22, 2023 •
edited

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kaj @wrapperup