Rails - Hotwire 
12 Apr 25
Amended the flow on MSP for client cancellations.
Originally the client would click cancel, which would trigger a general confirmation box, click ok and the cancellation request would be sent to the server.
Now when the client clicks cancel, this sends a request to the server, which responds with a turbo stream with specific cancellation details based on time of cancellation, which updates the div with id modal.
The client clicks again and a second request is then sent to the server (the original endpoint) and the flow continues in the original way.
Originally the client would click cancel, which would trigger a general confirmation box, click ok and the cancellation request would be sent to the server.
Now when the client clicks cancel, this sends a request to the server, which responds with a turbo stream with specific cancellation details based on time of cancellation, which updates the div with id modal.
The client clicks again and a second request is then sent to the server (the original endpoint) and the flow continues in the original way.
- a stimulus controller to close (cancel) the confirmation box using:
hide(event) {event.currentTarget.closest('.modal')targeting the element with id modal would also be fine
event.Target would also be fine here, but event.currentTarget ensures we refer tot the element with the event listener attached (rather than some other element nested inside that was actually the element clicked)
passing event
event.Target would also be fine here, but event.currentTarget ensures we refer tot the element with the event listener attached (rather than some other element nested inside that was actually the element clicked)
passing event
- understanding the bootstrap modals have to be properly closed to enable underlying content to be active again. Originally to clear the modal i used:
<%= turbo_stream.update "modal" do %> <%= render inline:'' %><% end %>
but simply clearing the modal didn't allow the underlying content to become active again (probably because of display properties of the modal being fixed...). I resolved this by replacing the entire modal with an empty modal partial.
<%= turbo_stream.replace "modal" do %> <%= render partial: "empty_modal" %><% end %>
- SASS in _modal.scss
@extend %modal-content-shared; to share a set of CSS properties, so modals can share a baseline set of values and have modal specific values
- pass variable that might not exist
passed this as a parameter in the client_update_booking_path route (so can then check on the server that the time of the request hasn't changed between initiating and confirming
time_of_initiation: time_of_initiation if defined?(time_of_initiation)
without the if defined? subsequent references to time_of_initiation will fail as it is considered undefined (not nil). This ensures it is at least nil.
- reminder that GET requests from inside a turbo stream do not have format turbo-stream.
It is possible this can be worked around by setting data: {turbo_stream: true.... (untested).
some quite detailed used of Minitest's match method
assert_select "form:match('action', ?)", /#{client_update_booking_path(booking, client_id: @client.id)}[?]/ do
assert_select 'input[name=?][value=?]', '_method', 'patch'
assert_select "input[type=submit][value='Yes, cancel booking']"
endCheck that the response HTML contains a <form> tag where the action (ie route) starts with the client's bookings path and includes a ? (i.e., a query string)
and within that form there is an <input> tag with name '_method' and value 'patch' [this is the Rails way to do a patch with an html form, as the HTML form itself can only have method 'get' or 'post'].
and within that form there is an <input> tag with name '_method' and value 'patch' [this is the Rails way to do a patch with an html form, as the HTML form itself can only have method 'get' or 'post'].
and another <input> with type submit and value 'Yes..'
