Swap content with server-side error

[Charles McLaughlin]

Hi,

I'm just getting started intercooler.js... thank you, it's wonderful!  

Is it possible to return a server-side error with html body and still have intercooler.js swap the content?

For instance, I have a html form which I validate... it seems "correct" to return a 400 error if it doesn't pass validation. But unless perhaps I'm doing something wrong, it seems intercooler.js doesn't swap the content in this case.

I briefly read about ic-on-error, but that doesn't seem to be what I'm looking for.

Thanks,

Charles

[Anders Baumann]

If it is a server validation then I would suggest to just return a regular HTML element with the error message. No need to use a 400 response.

[Carson Gross]

Thanks Anders,

I agree: we don't swap content when a server-error is detected since that content could be anything (e.g. a 500 error page, or a 404, etc.)

You could trigger a client-side event if you wanted to do something like show a popup message, but the cleanest most intercooler-y thing to do is to render the error message inline with the content.

Cheers,

Carson

On December 3, 2018 at 6:19:51 AM, Anders Baumann (baum...@gmail.com) wrote:

If it is a server validation then I would suggest to just return a regular HTML element with the error message. No need to use a 400 response.

--
You received this message because you are subscribed to the Google Groups "intercooler-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intercooler-j...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin Sampson]

I would even make the case that 200 is the correct response code in this case, conceptually speaking.

 

The HTTP status codes are primarily about protocol-level issues. 4xx means that the protocol request is malformed somehow. That could include, say, an unrecognized form parameter or URL path. But if the browser correctly gathered input from the user and correctly passed it along to the server, and the server processed the request without crashing (correctly identifying problems in the user's input), then 200 is the right code even though it's an "error" being returned, because it's a user-level error, not a protocol-level error.

 

Cheers,

Justin