Can't detect errors during form submissions

[iatanas0v]

We can override override fun onFormSubmissionFinished(location: String) to know when a form submission is completed but we can't inspect the result, was it 200 or 500 or something else.

Also I noticed that override fun onVisitErrorReceived is not called if an error occurs during form submissions

[jayohms]

The existing onFormSubmissionStarted() and onFormSubmissionFinished() callbacks were added to do things like:

• Display a native progress indicator during form submissions
• Enable/disable native controls during form submissions

What problem are you trying to solve where you need to know the response status of the form submission natively? It'd require some work to expose the form success/error callback from turbo.js to the native adapters.

[iatanas0v]

I'm trying to do good error handling, in case of 500, 502, etc I want to notify the user, right now the UI does nothing and can be confusing.

[jayohms]

Would it be sufficient to listen to Turbo form submission events in your web app and display a javascript alert when fetchResponse.serverError is true? The native libraries display javascript alerts as nice native dialogs.

[iatanas0v]

I guess it can work. It would be nice to have the ability to detect the response code in the future 🙏

[jayohms]

@joemasilotti do you already have a standard way to handle this? I agree that it'd be nice to expose the additional form submissions events, but there's some overhead to expose this in turbo.js and the native adapters.

[joemasilotti]

Currently, no. Non-200 form submission responses render the web-powered error form from Rails.

To be honest, I'm kind of surprised. That's not what I would have expected to happen. So I agree, I think we should definitely have a way to handle this on both platforms.

IMO, it should call the existing error callback like a GET request would if it returned a non-200 response code.

[jayohms]

IMO, it should call the existing error callback like a GET request would if it returned a non-200 response code.

@joemasilotti Can you clarify which error callback you mean here? I think a form submission error would need to be distinct from a visit error.

These are the two form submission error callbacks that I think could be exposed to the native adapters:

• formSubmissionFailedWithResponse(formSubmission, fetchResponse)- 4xx-5xx errors
• formSubmissionErrored(formSubmission, error) - network failures

https://github.com/hotwired/turbo/blob/9e057f284a60a9597446b258d562cebd55be71d7/src/core/drive/navigator.js#L92-L111

[joemasilotti]

I think a form submission error would need to be distinct from a visit error.

Why do they need to be different? Why can't we consolidate them into one error handler?

[jayohms]

Why do they need to be different? Why can't we consolidate them into one error handler?

I don't see a reasonable path for that implementation, and the expectations for how to treat visit errors vs form submission errors are completely different. Visit errors typically require displaying a full page error view while form submission errors could involve updating button/progress state, displaying a native dialog, offering a retry, etc.

The visitRequestFailedWithStatusCode(visit, statusCode) callback provides a visit object and corresponds to a visit that has already started and initiated by the app.

The existing turbo.js formSubmissionFailedWithResponse(formSubmission, fetchResponse) and formSubmissionErrored(formSubmission, error) callbacks correspond to a form submission that failed, but before a redirect and a subsequent visit has been initiated.

[joemasilotti]

Got it - that makes sense! Thanks for the explanation, @jayohms. As long as we can add default handling for both to the framework, with options to override, then I'm in favor of this.