Use namespace when you want to group routes under a common module (which will also affect the URL and helper methods). Use scope when you need more flexibility in terms of paths and controller organization, allowing you to keep the controller in the global namespace or in a different module than the URL might imply. The scope is often used when the URL structure doesn’t neatly map to the controller structure, which can sometimes be the case with APIs or user-facing URLs that need to be more SEO-friendly.

resources :posts do
	scope module: :posts do
		resources :publishes, only: :create
	end
end

# app/controllers/posts/publishes_controller.rb
class Posts::PublishesController < ApplicationController
	def create
		
	end
end

Prefix         Verb   URI Pattern          Controller#Action
post_publishes POST   /posts/:post_id/publishes(.:format)     posts/publishes#create

If we were to use namespace, it could look something like this.

namespace :posts do
	post `publishes/create`
end

I am working on a new Ruby on Rails project with a friend. We bumped into a few development blockers that I have never experienced before. It turns out that if you are using an outdated version on npm, the pacakage.json which gets generated when you create a new Rails application will not include the necessary scripts needed in order to get ./bin/dev working.

Assuming your Ruby on Rails application is using cssbundling and jsbundling–if you see any build errors when trying to run the server with ./bin/dev you may want to try the following:

• First update your node version to a newer stable version. I set mine to 18.17.1. I use asdf to manage ruby and nodejs versions. asdf local nodejs 18.17.1
• Then update your npm version. I am using version 8.19.4. npm install -g npm@8.19.4
• re-install cssbundling rails css:install:bootstrap
• re-install jsbundling rails javascript:install:esbuild

In package.json, check to see if the scripts key includes five items for the value. Your Procfile.dev should look like the following:

web: env RUBY_DEBUG_OPEN=true bin/rails server
js: yarn build --watch
css: yarn watch:css

After updating npm and node version, yarn commands should work and you should be able to run the server with ./bin/dev.

If you are managing an application that has a staging version, you will need to point default_url_options[:host] to the correct host domain. If not, features that depend on host domains(i.e. uploading to cloudinary or sending out an email from your application)will not work.

# application_controller.rb
def set_default_url_option
  if ENV["HOST"]
    {host: ENV["HOST"]}
  elsif Rails.env.production?
    {host: 'https://app-name.com'}
  else
    {:host => "localhost", :port => "3000"}
  end
end

Set env variable in your staging app

heroku config:set --app app_name_staging HOST="https://staging.app-name.com"

I recently had a job interview for a Junior Rails role with a company. I was tasked to complete one of three exercises, one of which was a to-do list. I decided to utilize hotwire in order to expand my understanding of it.

I’m working on a Rails 6 project that is still dependent on sprockets. Which means I am often clobbering and precompiling when cleaning up on CSS styling. Setting up aliases help me save time.

alias rap='bin/rails assets:precompile && bin/rails s'
alias rac='bin/rails assets:clobber && bin/rails assets:precompile && bin/rails s'

Update–

You might not have to clobber and pre-compile. It may be an issue with a webpacker dependency. To fix, try deleting public/packs and public/assets.