Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR implements support for rendering named template fragments, which allows returning only specified parts of a page (useful for HTMX optimisations). It extends the HTTP handler, adds fragment context logic, updates tests, examples, and documentation.
- Extend
ComponentHandlerwith fragment buffering and streaming paths (WithFragments) - Implement
Fragmentcomponent and context to route output to the correct writer - Add unit tests for handler and generator, plus an HTMX example and docs update
Reviewed Changes
Copilot reviewed 13 out of 14 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| handler.go | Add FragmentNames field and new render paths (ServeHTTPBufferedFragment, WithFragments) |
| fragment.go | Implement fragment context, Fragment.Render logic |
| handler_test.go | Tests for fragment rendering and streaming |
| generator/test-fragment/* | New templ generator tests and template files |
| examples/htmx-fragments/* | HTMX example template, generated code, Go module, and README |
| docs/docs/03-syntax-and-usage/19-fragments.md | Documentation for fragment feature |
Comments suppressed due to low confidence (3)
docs/docs/03-syntax-and-usage/19-fragments.md:27
- The code sample references
templ.WithFragment, but the actual API istempl.WithFragments. Update the sample to use the correct function name.
handler := templ.Handler(Page(), templ.WithFragment("name"))
handler.go:159
- Update the comment to match the function name and behavior, e.g.,
WithFragments sets the names of fragments to render.
// WithFragment sets the name of the fragment to render.
…ture Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
This looks good! I think this will be very useful! 2 notes:
|
|
Both brilliant points as always. Current behaviour in the PR is to render anything with the name, even if there's multiple fragments with the same name. Happy with that? Agree with the helper function, great idea, would simplify the tests too, I think. |
|
Yep, that behaviour was intuitively what I expected when I read the docs, so makes sense! If we go with the helper function, does it make sense to make the context functions private, shrinking our API surface? Only expose the RenderFragment and WithFragment functions for now? Maybe to match the other function signatures the helper should actually be:
|
|
Thinking about uniqueness. I wonder if instead of accepting a string we could accept type nameFragmentKey struct {}
var NameFrag = nameFragmentKey{}
templ Page() {
<div>Page Header</div>
@templ.Fragment(NameFrag) {
<div>Content of the fragment</div>
}
} |
|
Great idea @joerdav - it allows people to avoid name conflicts. |
|
I've implemented your suggestions @joerdav. |
This PR adds fragment rendering support.
It enables an optimisation for HTMX by returning a smaller HTML payload when an entire document is not required. When carrying out a
hx-getor similar, if an entire page is returned thehx-selectattribute (https://htmx.org/attributes/hx-select/) needs to be used to select the subsection of content to replace. This enables the server to return only the requested content.The fragment concept is discussed further in https://htmx.org/essays/template-fragments/
I've included a docs update, a HTMX example, tests for the HTTP handler, and a set of generator tests which can further explain the feature.