Bashar Not that I'm aware of. Check for JS errors.

Using a turbo_frame_tag will allow us to make a request to the Rails server and replace the turbo_frame_tag with something else. In this case, we needed to create an input box with a value of the iframe element so it can be embedded. Since we're creating a token for the embedded link, we needed to get some response from the server with this new record's token.

You can do a search of episodes that reference turbo_frame_tags with code:turbo_frame_tag as the search params. https://www.driftingruby.com/episodes?query%5Bname%5D=code%3Aturbo_frame_tag

You should still be able to adopt a lot of this episode's code to accomplish this.

Have a look at this episode https://www.driftingruby.com/episodes/docker-on-rails-7 as I think it covers a lot of the issues that you may have. I'll try to fill in some of the gaps as well.

database.yml - This is getting covered by having the environment variable in our docker-compose file. DATABASE_URL=postgres://postgres:postgres@postgres:5432 is getting set and available to the Rails container. in the database.yml file, you'd just need to add

development:
  url: <%= ENV['DATABASE_URL'] %>

Tests - An alias that I use from that episode is dcr. I will run this command to pull up a shell in the Rails app container. From there, I can run my tests as I normally would. Though, I do run system tests as headless. 

dcr bash

Conflicting ports - You need to decide which services you want to use and where they are. If you have a postgresql instance that you keep installed locally for various reasons, but want to spin up a docker instance of postgresql for your development, you're going to have to change the ports on one of the running instances. That really is up for you to decide, but I would recommend changing the port for the one that you interact with the least.

Working through a feature in a docker dev environment - I'll use the dcr alias for anything that I need to do when interacting with a running container. However, for pushing to git, I keep my code on my host machine. It is linked through a container through the volume mounts. So, in that case, I would use my host machine's git to push to the repository.

Caching & Multiple versions - I'm a believer that docker containers should be treated like cattle (verses pets). We should be able to destroy and recreate them without issues. If I have a situation where I'm installing a bunch of gems, I may specify a directory and use volume mounts.

custom Rails application template - I have an episode for that! https://www.driftingruby.com/episodes/easy-deployments I use this methodology for any application that I'm creating. Combined with the next episode after that one, I can create a new dockerized Rails application that I use for development AND I can deploy it to a FQDN within minutes of creating the application.

Hope this addresses some of your concerns.

  01fe20bec001 It seems to work fine for me when I pulled down your code. 

The one difference is that I noticed that you did not have stimulus-autocomplete added to your package.json, so I added it with

yarn add stimulus-autocomplete