and easiest to implement too

@User What about something like this?

html
<button hx-on-click="get /route" hx-on-custom-event="get /update">button</button>

This provides flexibility in terms of assigning any event a specific request method and route.

It could get tricky with namespaced events

hx-on-namespace:event="get /route"

, but it's easy to read and understand.

This starts to feel a lot like hyper script. “on event get url then put it in #domnode”

it doesn't have to be. it's a question of having: 1. one route/method for all events (current) 2. multiple method/routes per event or groups of events everything else stays the same

htmx's extension system is great, so this can probably be implemented with an extension in a variety of ways.

Hey @User - you're totally right. It doesn't have to be. One factor that complicates things (currently) are all of the options that can be applied to those HTTP requests. They're very cool, but

hx-swap

hx-target

and others can all modify the original AJAX request in complicated ways. (I just saw the tip of the iceberg poking around in the SSE stuff)

The best solution for that problem was to have those target nodes "pull" what they wanted when the time came. Is there some way to use an analogous here?

Or, here's another way of putting my question: What kind of real-world example would have a developer needing to listen to two different kinds of events on the EXACT same node? Could this potentially be split into two nodes instead? Would that make the resulting code more readable?

In my particular case I wanted to trigger the request with a custom event to a "refresh" endpoint to reload the partial, while the click event would perform a different action. I already have a solution for this using an custom extension, so it's no longer an issue. If anyone here uses PHP for the backend and wants to take a look, I've been working on a framework similar to Sprig for CraftCMS and Laravel Livewire, but can be used on any project. Would love to get some feedback.

Hi. So, I need to develop a CMS as the basis of a research information system; but the backend has to be in Julia, just because I have so many data analysis. So, It'd be really interested to know what patterns you come up with and how they work. However, I couldn't use the code directly.

One of the important things I've learned when developing things is to ask... what's invariant. It's much easier to think about operations if they all are working on the same domain. What my development group implemented ~7 years ago (in Python) was a declarative screen system (yea, everyone does this) but what was novel about it, is that the thing it operated on was the user's "context". So, all operations had the notion that the user was at a particular place in the data structure they were navigating. Operations (with corresponding screens) moved the user from one context to another. By expressly tracking context within a content management system, and making it a first class entity; all sorts of neat things emerge.

@User -- I'm just shooting from the hip, but something like this might do it. A DIV anywhere in your code could host this particular behavior separately from the DIV that's actually getting refreshed:

<div hx-get="refresh-url" hx-trigger="custom:event" hx-target="#idToBeUpdated"></div>

That way, you're not bundling so much stuff into one div, and you can manage that separately from the click event in the div itself. Yes? 🙂

@User -- I'm working out a way to serve whole pages or partials based on the custom hx- headers in the HTTP request. This means separate chunks for the "chrome" vs. "content". I know I could just serve the whole page, then pick the IDs that I need, but serving less is simple enough, and it just feels right. Also, I'm using SSE to make real-time updates to the client webpage. The tag that subscribes to the SSE is within the main "content" section of the pages, so that it gets closed and re-opened on every page navigation. This makes it easy to tell the back-end service what page I'm currently on, and refresh it on every navigation. Are those the kinds of patterns you're looking for? I'm happy to post some sample code, if it would be helpful.

So, yea examples of how this could be used in practice with client & server would be great.

I also just discovered... https://lit-html.polymer-project.org/guide/writing-templates

Now, that's something I'd like server side.

@User So, you serve the main chunk via HTTP, then use SSE to fill in the rest of the page? So, let's presume we're building a replacement for https://teacherspayteachers.com -- and we need it to be responsive/mobile friendly. It's got chrome. Then though, are lots of various views to see products; sort of on an infinite scroll. That's one use case. I've also got traditional application use cases, only with SSE to keep client up-to-date as to how a long-running query is going and letting them cancel it.... being able to cancel is critical. Does this approach work with either of those use cases?

One downside of SSE based approach for large audience approaches is that you can't use a proxy to cache query fragments?

Sorry, SSE is just for push updates, like when there’s a new chat message. Infinite scroll, and page navigation all go through regular GETs, so all of that would work through a proxy just fine.

So, you'd use SSE for initial page population though?

Nope. That’s just a regular “GET”

Probably building the whole page and sending it as one (cacheable) file.

(Maybe) having some sub-page elements that come through later, such as additional pages of content. Think like the Reddit home page. The initial page loads, then infinite scroll loads subsequent pages when you get closer.

Right. So, anyway, I would love to see an example of how it your SSE usage might work.

> @User -- I'm just shooting from the hip, but something like this might do it. A DIV anywhere in your code could host this particular behavior separately from the DIV that's actually getting refreshed:

<div hx-get="refresh-url" hx-trigger="custom:event" hx-target="#idToBeUpdated"></div>

> That way, you're not bundling so much stuff into one div, and you can manage that separately from the click event in the div itself. Yes? 🙂 @User Yes, that could definitely be an approach to consider.

> Hi. So, I need to develop a CMS as the basis... @User And so it begins...

Observable HTL package... https://observablehq.com/@observablehq/htl is awesome.

Perhaps what I need to be sending up isn't HTML but these JS expressions; or better yet, something like HTL but server side.

@User So, I see a modern CMS as being convention over configuration; that is, a bunch of conventions and supporting libraries that let you build very customized CMSs for specific purposes, not the traditional frameworky thing.