Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx Is Composable?

timkellogg.me

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Htmx Is Composable?

#61

Post by hipadev23 »

infamia wrote: post #55
wg0 wrote: post #14

I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA. Any open source project done in HTMX that ha…

> I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. When you use `hx-boost` (one of the most common uses), it does an ajax request, updates all the child elements, and updates the URL in the browser automatically.

This needs to be higher. Works normally without JS enabled and doesn't require any header fiddling. By far the easiest way to integrate htmx while keeping a consistent user experience.

Re: Htmx Is Composable?

#62

Post by _heimdall »

larve wrote: post #15
mejutoco wrote: post #12

Earlier quoted context omitted.

I think the key feature of htmx that often people overlook is that you can update several elements with one html response The attribute is the following: https://htmx.org/attributes/hx-swap-oob/

that's even easier to do in react though. If I say, update the cart, and update my cart state in redux, then every component rendering the cart (say, header, checkout component, shipping progress bar) will update seamlessly. To me htmx seems weird in its mixing of logic / API separation layer with the UI separation layer. I can see it making sense on single/small team projects and appreciate the lack of bundling and…

That's where looking at HTML as serialized state really helps. When a request changes the cart the server responds with chunks of HTML "state" for anything that changed.

In the shopping cart case, a user clicks Add to Cart and the server responds with an update for the button (maybe it has a success message) + new HTML for the cart item counter in your header. Sure that counter is technically UI, but the server is sending it because the state has changed and the client needs to patch in the update.

Re: Htmx Is Composable?

#63

Post by lucasyvas »

recursivedoubts wrote: post #48
lucasyvas wrote: post #42

Earlier quoted context omitted.

That's OK - but then I'd say I'm not interested in it based on its project scope. I have enjoyed it for small demos but I wouldn't pitch it to my company to use in the real world based on its philosophy.

And yet, and yet: https://htmx.org/essays/a-real-world-react-to-htmx-port/

I've read this and think it makes a ton of sense. I still think it's lacking an ecosystem strategy that would propel it further.

I would like be able to install an HTMX component, customize the route, and have some type of lifecycle where I can plug it into the rest of my backend. I know this might seem silly but being able to easily share what you've built has been a cornerstone of every widely successful library or framework.

It may not be a core goal of HTMX, but if not I'd really like to see someone attempt it to at least judge it on its merits instead of assuming it wouldn't be a useful addition.

If I can cargo install an HTMX component that covers all the rendering conditions and I just need to pipe data in and out of it, I'd very much like to try that. I can rig it up in my own codebase but it's not something one would probably publish without a suggested pattern to follow.

Re: Htmx Is Composable?

#64

Post by paranoidxprod »

sesm wrote: post #59
paranoidxprod wrote: post #52

Earlier quoted context omitted.

As mentioned in that comment, there is hx-swap-oob, but there is also the official htmx multi-swap extension that makes this pretty trivial. https://htmx.org/extensions/multi-swap/ In that example, you'd just send partials for the card and cart elements and they'll both be swapped out.

If we continue the cart example, what should HTTP endpoint return in that case?

In this example, the html for the card which looks different and the cart with the updated count could be returned. HTMX will swap both with the appropriate element based on the ids of the elements in the Dom and the elements being returned by the server and this won’t cause a whole page refresh or anything.

Re: Htmx Is Composable?

#65

Post by thunderbong »

hipadev23 wrote: post #61
infamia wrote: post #55

Earlier quoted context omitted.

> I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. When you use `hx-boost` (one of the most common uses), it does an ajax request, updates all the child elements, and updates the URL in the browser automatically.

This needs to be higher. Works normally without JS enabled and doesn't require any header fiddling. By far the easiest way to integrate htmx while keeping a consistent user experience.

How the heck does HTMX work without JS? And in this specific example, they're making an Ajax call! Also, the 'j' in Ajax stands for 'javasxript'

Re: Htmx Is Composable?

#66

Post by hipadev23 »

thunderbong wrote: post #65
hipadev23 wrote: post #61

Earlier quoted context omitted.

This needs to be higher. Works normally without JS enabled and doesn't require any header fiddling. By far the easiest way to integrate htmx while keeping a consistent user experience.

How the heck does HTMX work without JS? And in this specific example, they're making an Ajax call! Also, the 'j' in Ajax stands for 'javasxript'

It doesn’t? Your site still does is the entire point.

Re: Htmx Is Composable?

#67

Post by yawaramin »

graftak wrote: post #56
tecleandor wrote: post #26

Earlier quoted context omitted.

The thing is... not everything needs the window url to be updated. Either because the URL is the same, or because you're pulling content that shouldn't/can't/won't be accessible with a direct URL. For example: - Blog: You add a comment to a blog post. The comment appears without reloading, and you don't need a new URL (because it's the same blog post) - Menu navigation: You load menu items and/or children via htmx. T…

For all your examples I can think of a reason to update the url in some or most scenarios. It depends. New blog comment can be part of the url target with the comment id. Makes it easy to share and puts the scroll bar at the right position. Menu navigation can be quite complex with nested modals, you might want to be able to deeplink for documentation/training purposes and highlight a selection. With a cart you might…

> With a cart you might want to add a ‘cart state/session’ id so you can share it

That might not work for carts that work by temporarily 'booking' an item, like a seat for a cinema ticket. By definition, the cart is unique to a user.

Re: Htmx Is Composable?

#68

Post by naasking »

wg0 wrote: post #14

I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA. Any open source project done in HTMX that ha…

> then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.

You don't need all of the tools you think you need. HTMX is reimagining SPAs by extending hypermedia. It doesn't yet extend as far as existing SPA frameworks, but it covers a much broader range than you think.

Re: Htmx Is Composable?

#69

Post by graftak »

yawaramin wrote: post #67
graftak wrote: post #56

Earlier quoted context omitted.

For all your examples I can think of a reason to update the url in some or most scenarios. It depends. New blog comment can be part of the url target with the comment id. Makes it easy to share and puts the scroll bar at the right position. Menu navigation can be quite complex with nested modals, you might want to be able to deeplink for documentation/training purposes and highlight a selection. With a cart you might…

> With a cart you might want to add a ‘cart state/session’ id so you can share it That might not work for carts that work by temporarily 'booking' an item, like a seat for a cinema ticket. By definition, the cart is unique to a user.

My local cinema actually allows this but the cart-session is tied to the user session so when you share it the page goes to readonly mode where only the time and chosen seats are visible.
Post reply on HN