diff --git a/docs/architecture.qmd b/docs/architecture.qmd index 768c839..7dfd136 100644 --- a/docs/architecture.qmd +++ b/docs/architecture.qmd @@ -95,12 +95,74 @@ The best solution, I think, is to use really robust client-side form validation Here are some patterns we've considered for server-side error handling: -| ID | Approach | Returns to same page | Preserves form inputs | Follows PRG pattern | Complexity | -|-----|----------|-------------------|-------------------|------------------|------------| -| 1 | Validate with Pydantic dependency, catch and redirect from middleware (with exception message as context) to an error page with "go back" button | No | Yes | Yes | Low | -| 2 | Validate in FastAPI endpoint function body, redirect to origin page with error message query param | Yes | No | Yes | Medium | -| 3 | Validate in FastAPI endpoint function body, redirect to origin page with error message query param and form inputs as context | Yes | Yes | Yes | High | -| 4 | Validate with Pydantic dependency, use session context to get form inputs from request, redirect to origin page from middleware with exception message and form inputs as context so we can re-render page with original form inputs | Yes | Yes | Yes | High | -| 5 | Validate in either Pydantic dependency or function endpoint body and directly return error message in JSON, then mount it with HTMX or some simple layout-level Javascript | Yes | Yes | No | Low | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDApproachReturns to same pagePreserves form inputsFollows PRG patternComplexity
1Validate with Pydantic dependency, catch and redirect from middleware (with exception message as context) to an error page with "go back" buttonNoYesYesLow
2Validate in FastAPI endpoint function body, redirect to origin page with error message query paramYesNoYesMedium
3Validate in FastAPI endpoint function body, redirect to origin page with error message query param and form inputs as context so we can re-render page with original form inputsYesYesYesHigh
4Validate with Pydantic dependency, use session context to get form inputs from request, redirect to origin page from middleware with exception message and form inputs as context so we can re-render page with original form inputsYesYesYesHigh
5Validate in either Pydantic dependency or function endpoint body and directly return error message or error toast HTML partial in JSON, then mount error toast with HTMX or some simple layout-level JavascriptYesYesNoLow
Presently this template primarily uses option 1 but also supports option 2. Ultimately, I think option 5 will be preferable; support for that [is planned](https://github.com/Promptly-Technologies-LLC/fastapi-jinja2-postgres-webapp/issues/5) for a future update or fork of this template. \ No newline at end of file