Replies: 3 comments 7 replies
-
I have a couple of thoughts. Nice work. I think it looks better in that it's much easier to reason what is going on under the hood when you can express a matching pattern for the route. I think there are some things I would still like to see:
Fragments are theoretically supposed to be a replacement for extracting code for entire components. With a fragment you have no discernable lifecycle methods.. at least, how can I tell when it's appropriate to load all the data that will be needed for the full page request vs just the data needed for the fragment in the whole page OnInitialized and OnParametersSet methods? The matching approach makes it possible for the fragment to know it needs to render, but how do you discern with the regular component lifecycle methods which is the data you want to load? Could fragments themselves have some event methods that you could hook into in order to load data for that fragment? I've looked over a few other working implementations of template fragments and there are some commonalities. Most of the template fragment implementations requires explicit names for the template fragment. While you are taking a different approach I could still see points in time where a developer would would want to render fragments by name. One of the nice things I saw when it comes to other Template fragment implementations is that a common pattern is to load some model data and then directly render a fragment of a page by calling the page and named fragment and passing the model parameter. I think that is a really versatile alternative. With existing .net technologies I can render a razor component from a minimal api using a RazorComponentResult, which just returns IResult (also used by MVC, RazorPages) Would it be possible to allow Htmxor pages to be rendered to an output stream as well? Some thoughts. HtmxFragment would need to have a fragment Id. Then expose a public renderer with a method like below akin to HtmlRenderer which is also used by RazorComponentResult I believe: public Task<HtmxorRootComponent> RenderComponentAsync(Type componentType, string fragmentId, ParameterView parameters) Not sure if this could make this doable but perhaps add an internal nullable string property called FragmentId to HtmxRequest. When not null, the HtmxFragment Match function on a HtmxFragment is overridden by one that could be set to return true when the fragment id in the fragment matches the FragmentId in the HtmxRequest? Anyway that's all for now. I need to think about this some more but I think this is closing in on a nice solution. |
Beta Was this translation helpful? Give feedback.
-
Just to be clear I think that the match approach is fine. I just think that the option to render on the id of the fragment should also exist. Covering the lifecycle methods for now. I'm going to come up with an example where the data isn't tied into the same feature. Let's say we have a news page where the main content is a list of latest articles and it has a sidebar with several cards featuring different types of content. As the user scrolls I want to load in additional articles automatically, targeting the end of the main content container. For the sidebar boxes I have one that is a list of latest comments from users and a list of top articles. I also want to place the newest comment in a special box at the top of the page above the article list. There is also a navbar and other elements that are part of the main template for the site, so this initial page content will typically be loaded via an htmx request and will target a div with id "page_content". On scroll the last article has hx-trigger="revealed" to make a call to retrieve page 2 of latest articles. Only articles will be updated, so the targeted element will be the main content area after the end. All other parts of the page should remain the same. Every 30 seconds I will poll for latest comments and refresh the comments box with the latest comments. The special box on top will be updated with the latest comment using an OOB swap. For this example, we have:
On an htmx request to to /news with target of #page_content
On an htmx request to /news?page=2 with target of #articles and swap method of afterend
On an htmx request to /news/comments with a target of #comments
How would you approach this example? |
Beta Was this translation helpful? Give feedback.
-
Here are three new implementations of the https://htmx.org/examples/update-other-content examples from htmx.org. The expand the target example: The OOB example: The event triggering example: Let me know what you think! |
Beta Was this translation helpful? Give feedback.
-
This is a small sample inspired by original template fragments article. This could be one way to enable this pattern in Htmxor.
In the example, during a standard request, the full page is rendered. During a
hx-patch
request, only the content of the<HtmxFragment>
where theMatch
predicate returns true is going output markup.(since updated - see https://github.com/egil/Htmxor/blob/examples-project/samples/HtmxorExamples/Components/Pages/Examples/ArchiveToggle/Index.razor).
The
HtmxFragment
component itself is pretty simple:Htmxor/samples/HtmxorExamples/Components/HtmxFragment.cs
Lines 1 to 31 in a65d3c9
@tanczosm what do you think?
Beta Was this translation helpful? Give feedback.
All reactions