-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validation & Error Bags #30
Comments
Hey @antoniosarosi thanks for raising this again. I'm very much a Rails/Laravel-minded developer who's built a few apps in Django so I'm sure I missed some of the intricacies of how Django's built in forms work. My first thought is that explicitly providing the error url seems very pythonic to me; it's obvious and doesn't rely on magic to implement. I also think it makes sense to integrate this into the existing middleware. It seems like this would be core functionality and, as a user, I wouldn't expect to have to add additional middleware to use it. |
@BrandonShar I already have a basic working example using a separate middleware in my Django app. I'll copy-paste-refactor the code into the built-in Inertia middleware and submit a PR so we can discuss this further. I also love Laravel, but Django does things differently, particularly when validating forms they don't |
I'm not using Laravel, but the Inertia documentation suggests flashing form errors into the session and then redirecting to the form page. Render could automatically extract errors from the session into page.props.errors. It could do the same with the session messages key, enabling the Django messages framework to work with Django-Inertia. Having build_props in render to automatically extract errors and messages from request.session might be a naive implementation of this. At the moment, I wrap inertia.render to do exactly this. Then, we just have to put form.errors in the session and redirect. |
This doesn't seem to be implemented. Is anybody working on it? If not, I can submit a PR myself. I'm thinking something like this will work just fine:
For this to work properly in all cases we need to know the route where the user is coming from. Django doesn't store the previous route in the session like Laravel does, so there's no equivalent of Laravel's
return back()->withErrors()
. You can emulate thereturn back()
part using the HTTPReferer
header as suggested here or by sending anext=URL
query param in the request as suggested here.However, the
Referer
header can't be trusted in all cases and thenext
query param requires changing the frontend code. So I'm thinking of 2 possible solutions, either implement Laravel's behavior of storing the previous URL in the session to provide areturn back()
function or just provide the route at validation time:Second option is more verbose but easier to implement, and it can coexist with the first option since we could make
error_url=None
by default and grab the route from the session. I guess all this could be a separate middleware that basically catches theinertia.ValidationError
, allowing the users to opt-in by adding the middleware tosettings.py
. Otherwise it could be integrated into the currentinertia.middleware.InertiaMiddleware
.Edit:
Issue #21 is related to this.
The text was updated successfully, but these errors were encountered: