egil, 5 months ago

@khalidabuhakmeh I do see some good opportunities to combine the two techs by creating custom versions of the Blazor rendered and NavigationManager, etc., perhaps a custom source generator as well.

Then the htmx.js script plus a friend would replace the blazor.web.js.

It could also very well be that the #Blazor team is planning to expand their enhanced navigation and form handling to do the same as HTMX is doing. @stevensanderson may know of any plans in that direction.

khalidabuhakmeh, 5 months ago

@egil @stevensanderson I did this sample that I think does what you want.

https://github.com/khalidabuhakmeh/BlazorHtmx

egil, 5 months ago

@khalidabuhakmeh @stevensanderson yes and no. I want a deeper integration. I'd like not to have to use minimal api but instead just use Blazor components directly with the '@ page' directive so everything is defined in one place.

Also not use the blazor.web.js and instead let htmx be the master in the client.

Probably a custom base component for HTMX fragment components/pages.

Do you think that would be valuable?

khalidabuhakmeh, 5 months ago

@egil this individual did something similar to what you're thinking, but I find it's really hard to follow.

He ended up making a base page.

https://github.com/westonwalker/BlazorMinimalAPI

khalidabuhakmeh, 5 months ago

@egil I think the philosophies are incompatible so the value comes from breaking the Blazor philosophy in favor of HTMXs.

Blazor is stateful whereas HTMX is stateless. It starts to get weird. So it could be valuable, but I think the maintenance cost would outweigh the value.

egil, 5 months ago

@khalidabuhakmeh yes and no. Blazor components can be stateless and just render output. That's what you are doing in your sample. I just want to make the backend more aware of HTMX, enable calling directly into components instead of having a separate endpoint handler, and have htmx manage the enhanced navigation / forms bits instead of Blazor because it is more evolved.

I need to prototype a bit and see if it makes sense.

Can you recommend a htmx demo that leverages many of its features?

egil, 5 months ago

@khalidabuhakmeh this is too complex for my taste too. I think I have an idea that makes things much simpler.

khalidabuhakmeh, 5 months ago

@egil I'd love to see what you're thinking. 😁

alexzeitler, 5 months ago

@khalidabuhakmeh @egil I'm curious as well. This has been nagging me since the release of .NET 8 and Blazor SSR.

egil, 5 months ago

@alexzeitler @khalidabuhakmeh I've been playing around with different ideas.

Here we have the "contacts app index page" with a custom <HtmxRequestView> component.

The code in (1) is shared independent of the request type (htmx/not htmx) and the FullPageContent component is able to reference the HtmxContent and include that (2).

You could even have multiple HtmxContent components that are used under different conditions (Triggers/Targets/etc.).

What do you think?
Am I on the right track?

khalidabuhakmeh, 5 months ago

@egil @alexzeitler that's pretty interesting. How does the component/page avoid rendering the layout?

khalidabuhakmeh, 5 months ago

@egil @alexzeitler that said, I can see this working. I only worry about repetitive and unnecessary execution of lifecycle events and loading data.

That said, you could use Lazy values to only evaluate expensive calls when used.

egil, 5 months ago

@alexzeitler @khalidabuhakmeh there are no double executions in this case.

egil, 5 months ago

@khalidabuhakmeh @alexzeitler the App.razor uses the same HtmxRequestView component only include the Router component for HTMX requests. Then I have a custom HtmxRouterView component in the Router component that skips the layout for HTMX requests.

Still just just experimenting with the "dev experience", so things are a bit hacky.

khalidabuhakmeh, 5 months ago

@egil @alexzeitler I think it looks pretty good as an approach. Great start.