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

URL-Driven State in HTMX

lorenstew.art

Post reply on HN
Print view View original

131–140 of 188 posts

Re: URL-Driven State in HTMX

#131

Post by purerandomness »

runeks wrote: post #90
Twey wrote: post #15

The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).

> The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. Why is the content changing between refreshes not "(helpfully) bookmarkable"? The HN front page (ie. "page 1") does that but it's a very useful bookmark.

If you're bookmarking a directory, a list of things (e.g. the HN frontpage), you expect the content to change when opening the bookmark.

You bookmark a link to the directory so you don't forget the directory's entry URL.

The use case the author is talking about is a different one: You are configuring a complex item in a shop, and want to bookmark the URL so you can save it, recall it later, share this configuration with someone, or compare it with a different URL.

In this case, you also would expect little details to change (pricing, descriptions, photos) but the structure of the state should stay the same.

It's very frustrating when you share a link to a product detail page, only to discover that all your filters and configurations have been lost.

Re: URL-Driven State in HTMX

#132

Post by chuckadams »

donatj wrote: post #97
podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.

The browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.

Re: URL-Driven State in HTMX

#133

Post by trentnix »

PenguinCoder wrote: post #11
trentnix wrote: post #10

Earlier quoted context omitted.

I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped. It sounds like a similar use case to yours.

Are you able to share the code you have for this? I have a similar need use case and using golang and Htmx for my app.

I'll eventually make my repo public on Github, but I'm hesitant because it's still pretty half-baked. In the meantime, I'll do my best to capture the essentials. It's been a minute since I implemented it, so I apologize if I miss some details.

I use the same ViewModel structure for all renders, a struct called Content. It has a members to help with rendering and whatnot, and the data being rendered in my HTML template is stored in a Data type for the content that will be displayed:

  Data any
So whether I'm rendering complex data, a form, or just a snippet of text, that's where it lives. That allows for all sorts of patterns for rendering data and re-using templates if that's what you want to do. Or you can just keep things simple.

Hat-tip to the Pagoda framework, which was used sometimes as an inspiration and other times as a guideline for this (and other) patterns that I used. You can find it here: https://github.com/mikestefanello/pagoda

I also have, as part of my ViewModel, a `Notifications` slice that specifies messages to send to the user and their type:

  Notifications []messages.Notification
I have a HTML layout for my full page that includes a section that CSS uses to pick up notifications and display them via a toaster message:

  
    {{ range .Notifications }}
      
        {{ .Message }}
      
    {{ end }}
I managed to get it working without any need for JavaScript (other than what HTMX needs to work).

My partial renders use a layout that includes a section for the partially rendered code and my oob Notifications:

  {{ block "Content" . }}
      Loading content.
  {{ end }}

  
      {{ range .Notifications }}
      
        {{ .Message }}
      
    {{ end }}
So the hx-swap-oob results in my user-notifications being replaced with new notifications content, if there is any. I have a base renderer that handles injecting the layouts and injecting data into `Notifications`. As a result, my handlers can be generally oblivious that this is all happening underneath.

This model can work for updating links, updating breadcrumbs, writing messages to the console, or whatever.

I'm still scratching the surface with HTMX, but I'm convinced HTMX is perfectly appropriate and a much simpler alternative for 95% of the web dev being done today.

Re: URL-Driven State in HTMX

#134

Post by bob1029 »

jermaustin1 wrote: post #130
podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

I actually started my own PHP based on C# called CHP for fun. It runs atop whatever the current dotnet hosting service is (Kestrel?). It takes everything inside the " " code blocks and inlines it into one big Main method, exposing a handful of shared public convenience methods (mostly around database access and easy cookie-based authentication), as well as the request and response objects. Each request is JITed, then…

Have you looked into the string interpolation & verbatim operators as a templating alternative? These can be combined to create complex, nested strings:

  var reportPartial = @$"
    {report.Name}
    
      {string.Join('\n', report.Items.Select(reportItem => @$"
        
          {reportItem.Col1}
          {reportItem.Col2}
        
      "))}
    
  ";
In more complex views or reuse scenarios, I'd push the inner interpolation loop to a method.

This is how I've been building my .NET web apps for the last ~3 years. @+$ = PHP in C# as far as I'm concerned.

Re: URL-Driven State in HTMX

#135

Post by swiftcoder »

bob1029 wrote: post #79
podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…

> Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention

With modern CSS transitions, you can mostly fake this anyway. It's not like javascript apps actually achieve 0ms in practice - their main advantage is that they don't (always) cause layout/content flashes as things update

Re: URL-Driven State in HTMX

#136

Post by gortok »

So until about 2013? 2014? URL-driven state was just the way everything worked.

One of the major complaints of `cgi-bin` was that you had to manually add back to the URL to manage state (and of that time, there were a good number of cgi-bin applications that just didn't bother -- which unsurprisingly is how the SPAs worked at first until "URL Routing" took over).

But, all of this is literally just reinventing the wheel that's been there since the web began. The entire purpose of the web was to be able to link to a specific resource, action, or state without having to to anything other than share a URL.

What's wild is there are whole generations of programmers that started programming after the SPA world debuted and are now re-learning things that "were just the way things were" before 2013.

Re: URL-Driven State in HTMX

#137

Post by mardifoufs »

donatj wrote: post #97
podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.

Like a super rich and very well tested front end client, that doesn't need a server to template everything for it?

Re: URL-Driven State in HTMX

#138

Post by packetlost »

gortok wrote: post #136

So until about 2013? 2014? URL-driven state was just the way everything worked . One of the major complaints of `cgi-bin` was that you had to manually add back to the URL to manage state (and of that time, there were a good number of cgi-bin applications that just didn't bother -- which unsurprisingly is how the SPAs worked at first until "URL Routing" took over). But, all of this is literally just reinventing the wh…

tbh I always found it interesting that CGI was dropped as a well supported technology from languages like Python. It was incredibly simple to implement and reason about (provided you actually understand HTTP, maybe that's the issue), and scaled well beyond what most internal enterprise apps I was working on at the time needed.

Re: URL-Driven State in HTMX

#139

Post by ebiester »

bob1029 wrote: post #79
podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What does closing a modal mean? What does a sidebar mean? How about closing it? Pretty soon, you're in half-an-SPA already.

And since you don't want a 2000 character URL, you're either storing half of the session on the server or having to build an abstraction with local storage. And since our frameworks didn't evolve to handle that, what is the purpose?

The key insight into the SPA is that you are writing a coherent client experience. No SSR framework figured out how to do this because they thought about pages rather than experiences.

Let me be clear: I am speaking about web applications. If you're providing information and only have a small number of customer interactions, an SSR is superior. CNN should not be an SPA.

Re: URL-Driven State in HTMX

#140

Post by TimTheTinker »

ebiester wrote: post #139
bob1029 wrote: post #79

Earlier quoted context omitted.

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What doe…

> The key insight into the SPA is that you are writing a coherent client experience.

This is the best way to put it I've yet seen. HN articles keep saying things like "now that navigation transitions are solved in CSS, there's no use case left for SPAs". Is everyone just writing apps for widespread content consumption or something?

> CNN should not be an SPA.

Yes, and we need canonical "that should be an SPA"-type apps to bring up in these discussions--which can be hard, since all the best SPAs are for getting work done, not publishing content for the public to consume. Thus, as a class they tend to be department-procured B2B apps and not as generally recognizable. I propose GMail and Google Docs/Sheets/Slides for starters.

Post reply on HN