That does the trick.
This was a great series! I love the practical steps forward, and refactoring into components was wonderfully illustrated.
I'm experiencing a bug in the program, and I wonder if it's something specific to my code. When I move a card and then click to edit the name within a modal, the card title is correct, but the text in the input box is incorrect. For example, if I have a list with Item 1 and Item 2, then I drag Item 2 to the first location, then click on Item 2, I get a modal with the title "Item 2" but the text in the input area is "Item 1".
Are you getting the same behavior?
I am loving this series! This is such a cool project. The combination of acts_as_list and Vue makes it seem effortless.
I had one minor suggestion for the code in the cardMoved function. Rather than finding the list index, would it be better to just set a constant to the new list itself, and then use that object to set the list_id in the ajax request? Here's what I did:
Then when setting up data, I did this, which seems a bit cleaner:
Thanks for the great material!
This was an enlightening episode. Thanks for digging into the source to show us what's going on behind the scenes.
While discussing `Rails.linkClickSelector`, you mentioned, "you could be able to append stuff and move stuff from it as necessary." I'd like to ask you about that.
I would like to build a "verify" dialog box for deleting certain resources in one of my projects. The dialog box would work like the github dialog box for deleting a repo, in that you have to type the name of the resource in order to delete it. The idea is to make it impossible to inadvertently delete a resource.
The syntax I envision would be something like this:
link_to 'Delete event', event_path(@event),
message: 'NOTE: This will delete the event and all associated efforts and split times. This action cannot be undone. To verify, type the name of the event below and click Continue',
class: 'btn btn-sm btn-danger'
Do you have any ideas how to go about implementing something like this?
+1 for starting with tests on next refactoring episode.
One more thought: As you pointed out, many websites will want to accept both JWT requests and non-JWT requests via the same API. By adding `skip_before_action :verify_authenticity_token` without disabling non-JWT requests, don't we open a hole to CSRF attack from non-JWT requests?
Here's a possible solution; would love to have your thoughts.
In the API controller:
skip_before_action :verify_authenticity_token, if: :json_web_token_present?
In the User model:
class User < ActiveRecord::Base
In the strategy:
user = User.find(payload["sub"])
user.has_json_web_token = true
Love this series. I've implemented this devise/warden strategy in my own project. One correction: Because the `before_action` in the ApiController is changed from `:authenticate_token!` to `:authenticate_user!`, the `skip_before_action` in the AuthenticationController must also change to `authenticate_user!`, otherwise devise will reply with "You must sign in or sign up before continuing."
Keep the great material coming, Chris.