I have a table that makes up a very complex schedule. Each tr has a unique dom id. As the schedule is rendered, the duration of a schedule's time span dictates a colspan attribute. For example, a 9 day schedule span will colspan 9 tds and look like one section. That's too much info, really.
Each colspan td has a simple dropdown menu offering a few shortcuts like edit and delete. The entire table is wrapped in a turbo_frame_tag, so all links (without turbo_frame: '_top') will respond to turbo_stream format. The delete link is a button_to....to trigger the turbo_stream response in the destroy action.
The functionality of all this actually works perfectly. If a user clicks on the dropdown for a given schedule block, clicks the delete link...the :destroy action is hit, the record is destroyed, and the action responds to turbo_stream...which replaces the entire table row.
The problem is...for some reason, the content is not updated right before my eyes. Instead, the page jumps back to the top (without a page refresh), and if I scroll back down to where I was...the content has been updated via TURBO. I remember having issues like this in old school JS, but why would turbo_stream also do this? And, is there anything I can do to prevent it?
Using div's inside a table like this doesn't violate any standards, but I can't help but think I might be better off converting this to a sudo table built out of tags, etc. I'm wondering if doing that might also help the above issue. I'm not sure why it would, but manipulating tables seems to do weird things sometimes.
Thanks!
respond_to do |format|
format.turbo_stream {
render turbo_stream: turbo_stream.replace(
"user_#{ user_id }_crew_schedule_row",
partial: 'crew_schedules/partials/schedule_row',
locals: { user: @crew_schedule.user }
)
}
format.html { redirect_to redirect_path }
end
