Rendering of Htmxor pages / Addressable Fragments

[tanczosm]

I'm starting this as a new discussion because the other discussion is a bit busy as is. One of the aspects you mentioned was liking everything inside a single file/component. As I started drawing up what addressable fragments might look like it started looking more or less like pseudo-components. That's where with Blazor being component-based to begin with you can't necessarily follow the same patterns as some of the other template fragment libraries might. The other template fragment approaches give each fragment a name and you can pass parameters that can be specifically used by that fragment.

It doesn't make sense to try to do this with Blazor, so it's probably best if you need to go this route to break things into individual components where necessary. I think your solution will cover a lot of use cases.

Would it still be possible to render out Htmxor pages with something akin to RazorComponentResult using the Htmxor renderer? If there are differences between what RazorComponentResult renders and what Htmxor renders I would love to see something like an HtmxComponentResult.

Source generators might be the best answer to create template fragments someday, but as long as you can't chain source generators that's going to be on pause for at least the current C# version.

[egil]

One of the aspects you mentioned was liking everything inside a single file/component.

Yes and no. It depends. I do not like large components/single file, I like things small as they are generally easier to understand. But things that logically fit together, e.g. like the toggle button in a row in a table, or more generally, things that do not make sense on their own, I like to stay together with the content where they do make sense.

As I started drawing up what addressable fragments might look like it started looking more or less like pseudo-components. That's where with Blazor being component-based to begin with you can't necessarily follow the same patterns as some of the other template fragment libraries might.

Exactly. An "addressable fragments" is just a component with a @page directive, or, just a component that other components can reference. To me, this is a component that makes sense on its own, and can potentially be used in multiple different contexts. One example of that would be the ContactEditForm here in the samples. It makes sense by itself, but can easily be leverage by other components/pages too.

The other template fragment approaches give each fragment a name and you can pass parameters that can be specifically used by that fragment.

What you are describing is a component. Components have names and take parameters. This is the advantage of the component model vs. more procedural template languages.

It doesn't make sense to try to do this with Blazor, so it's probably best if you need to go this route to break things into individual components where necessary. I think your solution will cover a lot of use cases.

Completely agree.

Would it still be possible to render out Htmxor pages with something akin to RazorComponentResult using the Htmxor renderer? If there are differences between what RazorComponentResult renders and what Htmxor renders I would love to see something like an HtmxComponentResult.

Absolutely. We need to create our own HtmxorComponentResult type, since RazorComponentResult is hardcoded to use EndpointRenderer indirectly through RazorComponentResultExecutor. EndpointRenderer is one of the key components that have been replaced in Htmxor.

Luckily, that is not a tall mountain to climb.

We need to copy the RazorComponentResult.cs file, and rename it to HtmxorComponentResult. It has a dependency on RazorComponentResultExecutor.cs which we also need to copy and name something like HtmxorComponentResultExecutor.

Feel free to create an issue for this, or even take a step at an implementation.

[tanczosm]

Sounds good. I'll work on this tomorrow morning.

…

On Tue, May 7, 2024, 7:35 PM Egil Hansen ***@***.***> wrote: One of the aspects you mentioned was liking everything inside a single file/component. Yes and no. It depends. I do not like large components/single file, I like things small as they are generally easier to understand. But things that logically fit together, e.g. like the toggle button in a row in a table, or more generally, things that do not make sense on their own, I like to stay together with the content where they do make sense. As I started drawing up what addressable fragments might look like it started looking more or less like pseudo-components. That's where with Blazor being component-based to begin with you can't necessarily follow the same patterns as some of the other template fragment libraries might. Exactly. An "addressable fragments" is just a component with a @page directive, or, just a component that other components can reference. To me, this is a component that makes sense on its own, and can potentially be used in multiple different contexts. One example of that would be the ContactEditForm <https://github.com/egil/Htmxor/blob/examples-project/samples/HtmxorExamples/Components/Pages/Examples/UpdatingOtherContent/ContactEditForm.razor> here in the samples. It makes sense by itself, but can easily be leverage by other components/pages too. The other template fragment approaches give each fragment a name and you can pass parameters that can be specifically used by that fragment. What you are describing is a component. Components have names and take parameters. This is the advantage of the component model vs. more procedural template languages. It doesn't make sense to try to do this with Blazor, so it's probably best if you need to go this route to break things into individual components where necessary. I think your solution will cover a lot of use cases. Completely agree. Would it still be possible to render out Htmxor pages with something akin to RazorComponentResult using the Htmxor renderer? If there are differences between what RazorComponentResult renders and what Htmxor renders I would love to see something like an HtmxComponentResult. Absolutely. We need to create our own HtmxorComponentResult type, since RazorComponentResult is hardcoded to use EndpointRenderer indirectly through RazorComponentResultExecutor. EndpointRenderer is one of the key components that have been replaced in Htmxor. Luckily, that is not a tall mountain to climb. We need to copy the RazorComponentResult.cs <https://source.dot.net/#Microsoft.AspNetCore.Components.Endpoints/Results/RazorComponentResult.cs> file, and rename it to HtmxorComponentResult. It has a dependency on RazorComponentResultExecutor.cs <https://source.dot.net/#Microsoft.AspNetCore.Components.Endpoints/Results/RazorComponentResultExecutor.cs> which we also need to copy and name something like HtmxorComponentResultExecutor. Feel free to create an issue for this, or even take a step at an implementation. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUHLRAOI5PMDY27VK7ZDADZBFQNZAVCNFSM6AAAAABHL3B2JOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNBXHE3DA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[egil]

I want to really highlight the point that template fragments are not a silver bullet, but it is a very nice bullet to have for specific scenarios.

The "Toggle Contact" example is a really good scenario for template fragments, the toggle button fragment feels natural to have directly in the page component:

https://github.com/egil/Htmxor/blob/examples-project/samples/HtmxorExamples/Components/Pages/Examples/ArchiveToggle/Index.razor

The "Updating Other Content - Triggering Events" I prefer just making the "ContactEditForm" directly addressable as a page. It makes sense to have the form directly addressable, very much in line with REST principles.

Created an updated example that shows that; these are the relevant files:

Htmxor/samples/HtmxorExamples/Components/Pages/Examples/UpdatingOtherContent/TriggeringEventsIndirectly.razor

Lines 1 to 33 in 32db085

	@inherits ConditionalComponentBase
	@page "/examples/updating-other-content/triggering-events-indirectly"
	<PageTitle>Htmxor - Examples - Updating Other Content - Triggering Events Indirectly</PageTitle>
	<h1>Updating Other Content - Triggering Events</h1>
	<p>This is a Htmxor version of the <a href="https://htmx.org/examples/update-other-content/#events" title="Updating Other Content article">Updating Other Content - Solution 3: Triggering Events</a> example at htmx.org.</p>
	<div class="d-flex flex-row gap-3">
	<table class="table w-50 border">
	<thead>
	<tr>
	<th>First Name</th>
	<th>Last Name</th>
	<th>Email</th>
	</tr>
	</thead>
	<HtmxFragment Match=@(req => req.Target == "contacts-table")>
	<tbody id="contacts-table" hx-get hx-trigger="newContact from:body" hx-swap=@SwapStyles.OuterHTML>
	@foreach (var contact in Contacts.Data.Values.OrderBy(x => x.Modified).Take(20))
	{
	<tr>
	<td>@contact.FirstName</td>
	<td>@contact.LastName</td>
	<td>@contact.Email</td>
	</tr>
	}
	</tbody>
	</HtmxFragment>
	</table>
	<div class="w-50 p-3 border">
	<h5>Create new contact</h5>
	<ContactEditFormPage />
	</div>
	</div>

This is the changed part from the original TiggeringEvents.razor:

Htmxor/samples/HtmxorExamples/Components/Pages/Examples/UpdatingOtherContent/TriggeringEvents.razor

Lines 29 to 34 in 32db085

	<div class="w-50 p-3 border">
	<h5>Create new contact</h5>
	<HtmxFragment Match=@(req => req.Method == HttpMethods.Post)>
	<ContactEditForm hx-post OnContactSave=@(() => Context.Response.Trigger("newContact")) />
	</HtmxFragment>
	</div>

You will notice that in TriggeringEventsIndirectly it does make sense to have the table rows be a template fragment that allows us to get the rows only. It would be odd to move that into its own component, because, during a standard request, they would not make sense on their own (table rows need a table/tbody).

Htmxor/samples/HtmxorExamples/Components/Pages/Examples/UpdatingOtherContent/ContactEditFormPage.razor

Lines 1 to 5 in 32db085

	@attribute [HtmxRoute("/examples/updating-other-content/contacts", Methods = [HttpMethods.Post])]
	@inject HtmxContext Context
	<ContactEditForm
	hx-post="/examples/updating-other-content/contacts"
	OnContactSave=@(() => Context.Response.Trigger("newContact")) />

This component just wraps the existing reusable ContactEditForm component, makes it addressable, and sets the response header.

[tanczosm]

I like to heavily use swaps and oob swaps to push changes rather than triggering a callback event. HTMX provides a number of mechanisms to achieve the same goal though. In the swap service idea I mentioned in issues I can, in code, enqueue some components during HTMX requests with parameters that I want oob swapped at any point in time without having to embed the change in markup.

The oob component list just needs to render before the response ends.

You can fire off toasts, trigger drawers to open with content, change small sections that might exist only in the template (like notification count) from any level of page interaction. Some of these interactions like toasts are transient but others like notification count are built into the layout and work naturally on a full refresh.

I also really like alpine.js with HTMX as well but that's another story.

[egil]

Yeah that's another pattern that makes sense.

I think section outlets are the right solution. For HTMX requests, you have one version of the outlets, probably in a htmx layout, and for standard requests you have another version that are declared in the normal layout component.

[egil]

@tanczosm added another that example shows how to do out-of-band updates using <SectionOutlet>, <SectionContent>, combined with htmx layouts and normal layouts, as well as how to do it through an injected service.

See https://github.com/egil/Htmxor/tree/examples-project/samples/HtmxorExamples/Components/Pages/Examples/OutOfBandOutlets