logo标签列表

为什么这个Rails 7中的link_to destroy嵌套资源，同时也试图销毁父资源？

ruby-on-railsruby-on-rails-7
3
我有两个模型：site和heading，其中site拥有多个headings。
我有一个销毁链接：

  <%= link_to site_heading_path(@site, @heading), data: { 'turbo-method': :delete, 'turbo-confirm': "Are you sure?"} do %>
    <i class="ti ti-trash"></i> Destroy
  <% end %>

以下是我的标题控制器方法，基本上只是默认的操作：

  def destroy
    @heading.destroy

    respond_to do |format|
      format.html { redirect_to site_path(@site), notice: "Heading was successfully destroyed." }
      format.json { head :no_content }
    end
  end

我已经写了这段代码一千次了，但在我的全新的Rails 7基础代码中，它却表现出奇怪的行为。

期望结果：

标题被删除，我被重定向到/sites/1

实际行为：

  1. 标题被删除（好的）
  2. 我可以看到重定向（很好）
  3. TURBO_STREAMS无缘无故调用了/sites/1上的DELETE方法（非常糟糕）

我不知道为什么会发生这件事。

这是webrick输出的结果。您可以看到它也试图删除该网站。我不知道为什么...

enter image description here

确实很奇怪。几乎就像是在重定向到site_path时，turbo-method: delete被重新提交了一样？我仍然卡在Rails 6上 :)但无论如何，您可以验证网络调用中重定向的turbo方法吗？ - Shaunak
2个回答
1

这并非一个新问题，以下是来自2013年的原文：

Rails Redirect After Delete Using DELETE Instead of GET

但是，随着 Turbo 的出现，这个问题变得非常重要。当从 JavaScript 的 DELETE 请求进行重定向时，浏览器将使用 DELETE 作为重定向位置的方法。解决方案是使用 303 重定向，它始终是一个 GET 请求：

redirect_to site_path(@site), status: 303
redirect_to site_path(@site), status: :see_other

我猜这应该算是有记录的：
在表单提交后，Turbo Drive期望服务器返回一个HTTP 303重定向响应，然后它将跟随并使用它来导航和更新页面而无需重新加载。具体请参考：https://turbo.hotwired.dev/handbook/drive#redirecting-after-a-form-submission。
0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接