ducky/web

• Commits
• Files

4:bd64a7d043d0 Go to Latest

ducky/web/src/components/ducky.svg

Start tracking server errors. We've been storing client-side errors for a while now, so we can say "hey that input you entered is really screwed up, please don't even bother submitting the form." But once we pass that hurdle, it's still possible that the server will say "I don't care what the client-side validation said, this input is still wrong." To achieve this, we needed to start tracking server errors and client errors _separately_. The plan, originally, was just to put them in a single array, all mixed together--and, of course, that's what our ValidationError component requires--but there's a usability problem with this. The server error could be "you don't have an internet connection" (using 'server-error' loosely...) or "hey, the server had a problem handling your request, try again." The problem with putting everything together is that all these "try again" errors should get displayed to the user, but anything displayed to the user causes the Register button to be disabled. Meaning they can't try again until they (unintuitively) change pretty much any field in the form. The answer was to separate the two types of errors into their own arrays, and disable the button based on the client-side error array. When displaying errors, we concatenate the arrays. This means server-side errors only get displayed, but do not disable the button. Of course, we can have server errors that can mean "your input is bad and you should feel bad", which are decidedly different from "try again later" errors. These "your input is bad" errors hypothetically _should_ keep the form from being submitted until the value is changed to a valid input. Unfortunately, if we get to the point where a server error is returned, we've already proven the client is incapable of determining between invalid and valid inputs for that specific condition. If the client were capable of knowing, the input never would have reached the server in the first place. So considering the point of disabling the form input is to prevent unnecessary requests to the server, we should never disable the form based on a server error, because (by definition) those requests _must_ be necessary, or the client-side validation would have caught them. TL;DR: disabling a form because of server-side errors is silly. We also fixed a bug in the ValidationError component that would cause any error without a field, param, or header value set (e.g., an error that only contains the error field) would be considered a match for _every_ input, which is not what we want. We still need to decide on logic for displaying global errors. On the naive level, it's easy: match '/' or '' as the field. But that ignores any error responses that we are not specifically looking for. I'd much rather have a catch-all ValidationError handler that will catch any error not already handled by the other ValidationError instances. Unfortunately, I can't wrap my head around a good way to denote that a ValidationError instance has handled a specific error. The best I've got is to do an InverseValidationError that tracks a list of fields, params, and headers (the inputs available for ValidationError) and handles any error that _doesn't_ match them. Unfortunately, for complex forms, this would involve quite a bit of manual bookkeeping, updating ValidationError and InverseValidationError components in sync and never forgetting to update one or the other.