Hotwire Discussion

2 usability questions re: turbo and forms

I’ve enjoyed updating an existing Rails app from turbolinks to turbo, however after increasing the hygiene in my controllers to use turbo with forms, I ran into a few UX issues out of the box:

  1. Rejected form submissions don’t reset the scroll position which is particularly awkward on mobile, with nicely formatted errors above the form, etc. Is the current/implicit recommendation to have a stimulus controller handle setting the viewport on turbo:submit-end?

  2. Out of the box, repeated rejected form submissions can look like a no-op, making a form feel completely unresponsive/broken. A browser visibly reloading is the defacto UX clue for “clicking the submit button worked”, so I’m wondering if there’s an implicit convention here that should be made explicit (animation? disabling the submit button?) or if a good default would be to always have the progress bar fire on form submission via turbo:submit-start? Related.

Thanks! I’m looking forward to shipping hotwire into production…

Hello, why not call a scroll-top stimulus controller when a form display an error and scroll inside the connect method?

Ran into a bit of a problem listening to submit-start and submit-end doing something like so:

document.addEventListener('turbo:submit-start', () => {
  Turbo.navigator.delegate.adapter.showProgressBar();
})

document.addEventListener('turbo:submit-end', (e) => {
  Turbo.navigator.delegate.adapter.progressBar.hide();
  if (e.detail.success === false) {
    e.target.previousElementSibling.scrollIntoView(true) 
  }
})

In particular, turbo:submit-end doesn’t seem to reliably fire on Safari 14.0.3 for me, despite the fetch request happening. It seems happy in Chrome. I do have rails_ujs installed, but disabled on forms.

If I wrap the form in a turbo frame, the event reliably fires but Rails is giving me a 302 back, not a 303, so the success condition doesn’t redirect…

This is 7.0.0-beta.3 and turbo-rails 0.5.7.