Discussion for a new feature - Template Fragments

[mat02]

Feature Request: Support for Template Fragments

Description
I’d like to propose adding support for template fragments in EdgeJS. When working with libraries like HTMX and DataStar, it’s often necessary to re-render small sections of a template in response to user interactions on the page.

Currently, this functionality can be achieved by breaking templates into components or partials. However, this approach tends to create an excessive number of small files, each containing minimal markup, which can make code harder to manage.

Proposed Feature
Introduce a mechanism to allow re-rendering specific subsections of a single template file without the need to split it into multiple components. This would streamline development while retaining the flexibility needed for partial updates.

Rationale
Adding support for template fragments would greatly improve developer experience when working with interactive libraries like HTMX and similar tools. For more context and examples, please refer to the following article: Template Fragments in HTMX.

[thetutlage]

Can you please share a technical proposal of how it will work? More specifically, when you want to render a fragment, do you expect Edge to process the entire template and return from the fragment output? Or do you expect Edge to only process the fragment contents?

Also, it will be essential to answer:

• Can fragments be nested?
• Can fragments be defined as partials or components?
• Can fragments live inside conditionals?

[mat02]

Thanks for your response!

Different frameworks handle this feature in various ways. For instance, in Laravel Blade, the entire template is rendered, and fragments are then extracted from the resulting HTML. However, this approach has clear performance drawbacks.
In contrast, jinja2-fragments renders only the selected fragment (block), with the calling function responsible for providing all necessary variables. I believe this approach is more efficient and better suited for implementation.

To address your questions:

Can fragments be nested?
Yes, fragments can be nested. For example, you could have a fragment that renders a whole table and another fragment that renders just a single row, see example below.

Can fragments be defined as partials or components?
I’m not entirely sure. My perspective is that this should work by "discarding everything outside the specified fragment and then rendering it as if it were a standalone template." This behavior feels closer to partials.

Can fragments live inside conditionals?
Again, I’m not sure, as I don’t have enough familiarity with the internal workings of EdgeJS. However, based on the idea in (2)—where only the contents of the fragment are extracted for rendering—would it matter if fragments were inside conditionals?

Proposed example of usage:

@fragment('fullTable')
<table>
  <tr>
    <th>Company</th>
    <th>Contact</th>
    <th>Country</th>
  </tr>
  @each(user in users)
    @fragment('singleRow')
    <tr id="row_user_{{ user.id }}">
      <td>{{ user.company }}</td>
      <td>{{ user.email }}</td>
      <td>{{ user.country }}</td>
    </tr>
    @end
  @end
</table>
<thead>
@end


(...)

const fullTableHtml = edge.render('template.fullTable', { users: await User.all() })
const singleRowHtml = edge.render('template.singleRow', { user: await User.find(123) })

[thetutlage]

I see. I think implementing the logic to only execute certain fragments will be challenging especially when they are the nested within conditionals or hidden behind components and partials.

For example: If a fragment is written inside a component, we will have to execute that component (infact all the components) and then grab fragments from there. Now imagine, component calls themselves are wrapped in certain conditionals, then we will have to evaluate those conditionals too.

I think, executing the entire template + extracting only the fragments should be the way to go. For those, who needs performance or are concerned with over data-fetching can use components and render them individually.

---

Given that, this is something a nice to have feature and I may not look into it right away given the amount of other tasks I have at hand.