Destroy link does not work

[sedubois]

What were you trying to do?

I want to destroy a record using the red "Destroy" link on the index view.

• What did you end up with (logs, or, even better, example apps are great!)?

Instead it simply shows the record, as if a GET was sent instead of DELETE, and so there is no way to delete the record.

• What versions are you running?
  • Rails 6.0.3
  • administrate 3a438eb

[nickcharlton]

Is this perhaps related to removing jquery-ujs in #1618?

My understanding is that that's what ensures the correct request occurs, but I'm sort of surprised it doesn't fallback

[sedubois]

@nickcharlton I confirm that by switching back to 3468644 (commit before the merge of #1618) the issue disappears.

[nickcharlton]

Damn. If you make sure rails-ujs is loaded for the Administrate Engine, does that help? I'm wondering if it's a Rails Engine compatibility issue.

I'm also surprised we didn't catch this on CI, so that's something to look at too.

[sedubois]

@nickcharlton I'm quite illiterate with this rails-ujs thing and rails engines, would you mind giving a bit more guidance?

[sedubois]

BTW (TL = Turbolinks),

The need for UJS is gone with TL6

Plan is to have TL6 out ~late summer/early fall

https://discuss.rubyonrails.org/t/turbolinks-doesnt-handle-render/74772/3
https://discuss.rubyonrails.org/t/turbolinks-doesnt-handle-render/74772/5

Maybe the change to rails UJS imports can be reverted and then upgrade to TL6 when available?

[nickcharlton]

I think we might just about know as much as each other here, but it seems like we expected the ujs removal to not be a problem as it was pulled in elsewhere so no longer needed. As for Rails engines, this sounds very similar to issues we've been having with the asset pipeline/webpacker and needing to do extra work to pull in dependencies.

Can you try on Rails 6.1? (or, perhaps replicate it with a failing test so we can see it on CI?)

[sedubois]

I don't have time to dig deeper with Rails 6.1 right now but for what it's worth the issue persists when commenting out turbolinks.start() in my admin JS pack.

[pablobm]

I looked into why this test passes with rack-test. I really didn't expect what I found...

Turns out that Capybara tries to be clever about data-* attributes used by Rails. Therefore, when it sees the link to delete a record, it issues a DELETE request instead of the expected GET. This apparently has been the case for a long time: teamcapybara/capybara#184

I created a branch where I tell Capybara not to be clever: master...pablobm:demo-clever-capybara It results in 3 spec failures.

I have also added this to https://github.com/thoughtbot/administrate/projects/1, and created a milestone "Release blockers". We should fix this before we release another version.

[nickcharlton]

Oh! Yikes, that's very unexpected. I did not know it did that by default.

What's the best thing to do here, given those failures?

[pablobm]

No idea 😓 I'm going to have to dive into the whole Rails/JS stuff to try clarify all this...

[mcmaddox]

Can this issue be reopened? I'm still experiencing this issue in v0.18.0 (Rails 6.1 with Turbo & Webpacker).

I added require("@rails-ujs") to the administrate.js pack, but the default link_to with method: :delete in show.html.erb view isn't recognized & sends a GET request that reloads the page instead of presenting the confirm dialog. I didn't think adding rails-ujs to the administrate.js pack was necessary since it's already in the application.js pack for my app.

Has anyone else resolved this issue in Rails 6.1?

[pablobm]

Hello @mcmaddox, thank you for reporting. Would you be able to share your administrate.js pack? I am not well versed on asset management, so I just created a Rails 6.1.7 app to check, and mine looks like this:

// This file is automatically compiled by Webpack, along with any other files
// present in this directory. You're encouraged to place your actual application logic in
// a relevant structure within app/javascript and only use these pack files to reference
// that code so it'll be compiled.

import Rails from "@rails/ujs"
import Turbolinks from "turbolinks"
import * as ActiveStorage from "@rails/activestorage"
import "channels"

Rails.start()
Turbolinks.start()
ActiveStorage.start()

So there's no require, and the correct name of the package is @rails/ujs (instead of @rails-ujs). Could it be that the problem lies there?