i've been toying with this idea using range requests. I wanted to make an infinite scroller using range requests to a gigantic static dom. you basically have to store a map of css or tag positions to bytes. currently trying to work one in to my proxy

By the HTTP spec: PUT creates or replaces a "resource" (likely your object) at the given URL; POST creates a resource by using a handler at the given URL; and PATCH is the verb for partial updates. Of the 3, PUT is considered "idempotent", a big word for "you can do it as many times as you want and still get the same result." In practice, POST can be (or is) used for all 3 scenarios. Early browser support for PUT and PATCH wasn't great (or existent), so web development fell into this "GET is for new pages, POST is for updating data" pattern. I'm not familiar with Django - but, specific to your question, either verb can return errors from the server. Any request can fail, so any request can return a status either in the 400 range for errors on what the user gave you (or their state), or the 500 range for unexpected errors that arise on the server. Hope that helps!

this is the rails convention, which is pretty good IMO

if it's hard to work w/

PATCH/PUT

on django, though, I wouldn't be ideological about it

I just came across htmx last week and am trying to consume as much info about it as I can. I come from a ColdFusion background, using CFML (the language on the backend) on CFWheels (a framework for CFML inspired by Rails). I'm very excited about finding out about this project. https://guides.cfwheels.org/docs/routing

I spent the first 9 years of my military career working on a system that was based on a network/hierarchical database. (The schema was defined in COBOL - configuration as code, before it was cool! LOL) This system (Unisys DMS) used the terms "records" and "sets"; sets connected records, and you could have automatic and manual set membership. Automatic sets were the equivalent of non-null foreign keys in a relational database. (There's a much longer story here, but I'll skip that part.) Anyway, a few years back, I decided to learn graph databases - why is everyone going crazy about this new data layout mode? As I dug in, though, I had an epiphany - this is the network model with dynamic sets! What's old is new again. 🙂 I ended up converting an application to use a graph database - then promptly discarding it. Holy cow, Neo4j used a lot of resources... And this was a tiny app; today, its bzip2'd document-database backup was 0.95 MB. I'm sure it solves some problems really well, but not without using more than its share of resources. (To be fair, that was several years ago; it may be better, and other graph databases may better as well.)

We managed to do some razzle dazzle for management with Neo4J's web interface. All those D3 bouncing balls. Never came to anything. Having spent far too long rendering DOCX files in a Django app, I'm also of the opinion that Open Packaging Conventions are basically a graph DB file format (https://en.wikipedia.org/wiki/Open_Packaging_Conventions)

As did I, long ago. You’re going to love htmx!

casual mention of htmx https://discourse.wicg.io/t/ability-to-explicitly-set-focus-visible-from-focus/5695

Hej, not sure how to handle formalities so I will just ask - I am using htmx to send some POST requests to the backend and return HTML. At the same time I send some updates via hx-ws for more fine grained control as I need to update multiple parts of the UI. The POST part works well as I can easily control the spinners etc. But I have noticed that hx-ws swaps do not trigger any of the htmx:* events ... is that by design or just missing as hx-ws is considered experimental?

I felt like asking here would be better than firing off a github issue ...

Hej, @fierce-optician-58974 — we’re in the middle of moving web sockets into a new extension, so depending on your project, I’d recommend you check out the dev branch for the latest syntax.

Since it’s in flux right now, this I s a perfect time to add events into the web socket code. For clarity, we should probably give them different names, but let us know what events are missing that you need, and I’ll see about getting them into the final release 😀

I am looking at htmx:afterSettle as I want to scroll the control to the newly insterted part (at least I think that's the event I should be looking at)

As they do oob swaps, should they not just emit the same events?

Minus the ... obvious request related ones

Ok, cool. The settling logic is a little different in web sockets. For now, we’re duplicating some of the logic buried in htmx because it’s not exposed to external packages (which we will now be)

I’ll add an issue to GitHub and see about including something like that before @mysterious-toddler-20573 cuts a release.

Great, thanks!

How about an event that will let it interface with hyperscript? Like an event that emits on connect, where I can use that websocket to send stuff down the connection to the server

(I can update the issue on Github with more information if you think this makes sense)

Yes, please!

The long term goal is to allow web sockets and SSE connections to be shared between the two libraries. Specifics of the implementation is still up for debate.

Right now, hyperscript’s web socket extension has a really great way of hoisting a proxy variable into the global JavaScript scope. I think it would be cool to hook into that from htmx, if both libraries are present.

I don't think htmx should have additional code to support that, but hyperscript should instead. In this case, having the websocket on connect could allow hyperscript to add support for HTMX, rather than the other way around. but yes, having the two play nicely would be amazing

Yes, I’d rather put extra code into hyperscript, too. But the way both libraries are currently built, hyperscript is much more modular and granular — you can do more with hyperscript’s SSE and websockets than you can with htmx.

No matter which way we go, connecting the two is still a ways away.

This stop on the "A Tour of myPrayerJournal v3" series doesn't reference htmx at all - but I'm sharing it here for completeness. 🙂 https://blog.bitbadger.solutions/2021/a-tour-of-myprayerjournal-v3/the-data-store.html