(unrelated to HTMX) I'm currently working on my form validation library for Nim, and was wondering if folks here tend to use a list of errors for a field or a single error. Many libraries I've seen (wtforms and django forms) seem to use a list of errors for any given field. Many websites I use however, seem to give a single error at a time (which I honestly prefer from a UX perspective, avoid overloading the user). Can someone give me a solid example or reason to have the validation errors for a single input be a list over just a single error at a time?

Someone, sometime (maybe a while ago on this board?) described their method that I've tried to follow since. 1. Client-side validation for everything, as fast, responsive, and inline as possible 2. Server-side validation to ensure that they're following the rules, but don't worry about error messages, because only cheaters will ever trigger it.

It may be an unpolular opinion (esp here) because "why do the validation twice?" but client side validation can work quickly with every keystroke, then use a common set of rules to validate twice: nice messages for rule-followers, and a big middle finger for rule-breakers.

Hm, so the way my library works is that you specify the HTML5 validation attributes (eg required, min, max...) and then I generate validators for those on the server side. My guess is that you're leaning towards the single string approach I described as it is simpler, and why waste time on a more complex solution for something that will likely be triggered by a bot/hacker/spammer.

Yeah, most forms in my app come from a JSON file + a schema object. On a "get", the schema is used to add HTML5 validators to the generated HTML. On a "put", the data is validated against the schema on the server before being allowed into the system.

I don't know if this works well in a generalized sense, but the results have been very nice, so far.

Cool, I'll go with that approach for now then! Unless someone comes up with a solid use case I plan to keep it this way (plus I haven't released it officially yet)

am I crazy, or does it seem like I should push all htmx interactions through a single top-level websocket?

I've been trying to build roughly isolated "components", with their own HTTP endpoints and such, but I've already got two websocket streams, and a handful of regular HTTP interactions here and there.

feels like a more "event bus" approach would be more efficient, and less like a mash of spaghetti

Yeah, I'd say just push them all into one single connection. Your server can combine them all easily, and htmx won't care where the oob-swap goes. They'll all be handled the same 🙂

I use SSE instead of WebSockets, but the principle is the same. Since TONS of different messages can fit in that same connection, I let one SSE EventSource do all the work, and let elements on the client figure out what to do with the info.

ok, glad I'm not missing something obvious

the one unfortunate bit is that the server will be controlling target IDs, etc; I'd much rather keep that element-local

Yeah, WebSockets and SSE's work a little differently because the two kinds of connections can carry different data natively. SSE has a message name, which makes it really nice for sending targeted messages. WebSockets doesn't have that, so we use oob-swaps instead. But, with a little extra work, you can mock it up using hyperscript's WebSocket code instead. With hyperscript, you can write your own code for parsing the WebSocket message, so you can be more intelligent with what happens next.

I just finished writing this up to answer @User's question in #909436816388669530. It applies (a little) to your WebSocket questions here, @User:

@User - Regarding live updates (from the #909436816388669530 channel) here's how I do it: 1. A directory watcher waits for changes in the "templates" directory and pushes updates to a central channel. [https://github.com/benpate/ghost/blob/03293af5ba441d58057d94509bf52b882be85521/service/template.go#L183] 2. A similar live query waits for changes to database objects [https://github.com/benpate/ghost/blob/master/service/streamWatcher.go] 3. Updates are fed to a Realtime Broker that tracks every browser client that's currently waiting on updates to a particular page [https://github.com/benpate/ghost/blob/master/domain/realtimeBroker.go#L8] 4. Specific browsers are notified via an SSE channel that "something about this record (called a stream) has changed. Only the streamID is sent via SSE. [https://github.com/benpate/ghost/blob/03293af5ba441d58057d94509bf52b882be85521/handler/sse.go#L76] 5. Each page that needs realtime updates uses a the new

hx-ext="sse"

extension alongside an

hx-get="" hx-trigger="sse:{streamId}"

to reload the specific view of the page that's just been updated.

I'll take a look, appreciate it 🙂

I've tinkered with hyperscript. Seems neat, but I'm not as sold on it. Would definitely be overdrawing my novelty tech budget if I added it in straight away lol

@User thanks for the overview. My question was more along the lines of development purposes. Eg... modifying some CSS and making it refresh.

Yeah, stick with htmx for as long as you can, then plug in hyperscript (or whatever) when you need something that htmx won't do.

This works fantastically for my development environment. As soon as I save a change a CSS or page template, the browser has already updated before I can CMD+Tab over to look at it.

You just have to watch the right folders 🙂

hrm.... reading......

Does anyone have an example of using the alpine-morph extension? I'm trying to use alpine with htmx and it seems this extension is the only solution to the problem I'm having. The morphdom extension doesn't seem to help because Alpine.js doesn't use morphdom anymore? Not sure.

Basically I have a textarea who's value should sync with an Alpine x-data object. I use x-model for this and it works as it should. The only issue is, when the innerText of the textarea is swapped by htmx the x-data object doesn't update as it should. I think this will work if the alpine-morph swapping function is used instead.

I'm just going to use _hyperscript lol I see an example that looks like it work fine without the extra support

@User everything over websocket has a meteorJS flavour to it. Very interesting

Hi all, would anyone be able to help me with a htmx triggering issue I am having?

What’s not working? (Not that I’ll be of any help but let’s see)