3 ms·

I don't see any reasonable way for htmx to do error handling without writing your own JS, it has an example of 'ic-post-errors-to', but that only seems to be fo

I don't see any reasonable way for htmx to do error handling without writing your own JS, it has an example of 'ic-post-errors-to', but that only seems to be for error tracking and requires writing a whole other dialect of js (hyperscript). Examples like https://htmx.org/events/#htmx:validation:validate https://htmx.org/events/#htmx:validation:validate also seem weird. Basically it replaces JS with it's own scripting dialect that is written inline in a attribute and that dialect does not even have syntax highlighting on their own site. Is it actually more simple than writing the equivalent html+js when you add on all the real-world requirements?

recursivedoubts 6y ago
Validation, as with the normal html request/response cycle, is done on the server side. Here is an example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html. The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting. Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx. From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.
- SahAssar 6y ago
  So how do you propose to do error handling? I mean proper error handling where you can show the user a meaningful message and that can handle normal stuff like timeouts, 500's 400's and so on.
  - recursivedoubts 6y ago
    Ah, you mean system errors, not application-level errors. App errors are handled the normal way. I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available. So you can write a three liner to handle it: htmx.on("htmx:onLoadError", function(evt) { htmx.find("#error-div").innerHTML = "A network error occured..."; // or whatever } This isn't code that would be hit regularly, unless your application or the network is in pretty bad shape.

recursivedoubts 6y ago

Validation, as with the normal html request/response cycle, is done on the server side. Here is an example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html. The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting. Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx. From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.

SahAssar 6y ago
So how do you propose to do error handling? I mean proper error handling where you can show the user a meaningful message and that can handle normal stuff like timeouts, 500's 400's and so on.
- recursivedoubts 6y ago
  Ah, you mean system errors, not application-level errors. App errors are handled the normal way. I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available. So you can write a three liner to handle it: htmx.on("htmx:onLoadError", function(evt) { htmx.find("#error-div").innerHTML = "A network error occured..."; // or whatever } This isn't code that would be hit regularly, unless your application or the network is in pretty bad shape.