Awkward behavior around redirects & error codes

[hotwired]

Awkward behavior around redirects & error codes

[dhh]

Wups, posted on the wrong issue. But you can now opt out of Turbo processing using the data-turbo=false attribute. I believe that should probably solve this? Might want to add a doc note about it.

[miharekar]

In case someone lands here trying to get Devise working with Turbo - there's been several workarounds/improvements suggested on Hotwire Discussion.

There's even a GoRails video with instructions.

[dhh]

You can now render on POST using either 4xx or 5xx status codes. In Rails, you'd do:

    respond_to do |format|
      if @room.save
        format.html { redirect_to @room, notice: 'Room was successfully created.' }
        format.json { render :show, status: :created, location: @room }
      else
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @room.errors, status: :unprocessable_entity }
      end
    end

Part of 0.5.3.

[davegudge]

The responders used by Devise have been updated heartcombo/responders#223 (pending a new release). Once released, the open PR for Devise can be finalised heartcombo/devise#5340

[dhh]

Would if Devise has something in place to detect all requests that come from fetch as XHR somehow, and then not do the HTML rendering if then? Maybe dive into that Devise chain and lets see if its something we have to fix there or if there's anything we can do on the turbo side.

[woto]

I remember that old turbolinks/turbolinks-classic had special code for Devise:

By default, Turbolinks includes itself in ActionController::Base. To opt out of the Turbolinks features in certain controllers (redirect_to behavior, request_method cookie, X-XHR-Referer referrer check, etc.), set config.turbolinks.auto_include to false in application.rb and include Turbolinks::Controller in the controllers where you use Turbolinks.

And Devise even has some hint here on how to use it

Also temporary stucked with Devise redirects :)