Sorry everyone for the late reply!
In the end I went to an approach very close to what @rockwell described with views named such as
“new.turbo_stream.html”, “edit.turbo_stream.html” and containing stuff like
= turbo_stream.replace :new_project_time, partial: ‘form’.
With that approach I don’t need to use respond_to { format… { … } }
I still need to wrap my views sometime inside of turbo frame but I’m thinking it’s much less mandatory than I though because the turbo_stream_replace can target any ID and not only a turbo_frame.
Another thing that is good to know is that data-turbo-frame is being passed as an header, so you can use it back in your response.
@woto I understand the frustration of not being able to use link_to as turbo_stream, but from experiences it seems useless. See, if you use a turbo_frame in your view, the frame content is going to be replaced dynamically by an HTML (not turbo_stream) rendered view. However, in some case where you would submit let’s say a form, the form will be submitted as turbo_stream and that’s where
new.turbo_stream.erb
edit.turbo_stream.erb
comes handy because by doing this:
= turbo_stream.replace :id_of_the_form, partial: ‘form’
you get to rerender the form dynamically with validation errors inside. I did need this on my form though
data: { “turbo-frame” => “_top” }
In the end, if you want to support both new_post_path from within a modal and a page (direct link), then using the approach with accept_turbo_stream_controller from @rockwell is the only approach that comes to my mind right now unless you check for the header presence of Turbo Frame (data-turbo-frame)