DEV Community: Olumuyiwa Osiname

Rails 8 Strong Parameters: The Double-Bracket Fix for Nested Attributes

Olumuyiwa Osiname — Sun, 11 Jan 2026 08:11:48 +0000

When upgrading to Rails 8, you may start using params.expect—often prompted by RuboCop’s Rails/StrongParametersExpect—to make strong parameter contracts more explicit.

There is a sharp edge: nested attributes submitted as indexed hashes can be silently filtered out, causing validations to fail in non-obvious ways.

This post documents a real failure mode we hit while building SoloBooks’ invoicing flow—and the fix that makes expect work reliably with Rails nested attributes.

All parameter examples below are simplified and anonymized to illustrate structure only.

The Problem: Invoices Failed Validation After Switching to `expect`

Invoices in SoloBooks must have at least one line item. After switching from require(...).permit(...) to params.expect(...), invoice creation began failing validation.

At first glance nothing looked wrong:

the request succeeded
parameters appeared present
no strong-parameter error was raised

But the invoice was rejected because no line items were actually assigned.

A request spec caught it immediately.

The Setup

Our Invoice model accepts nested attributes and validates presence of line items:

class Invoice < ApplicationRecord
  has_many :line_items, dependent: :destroy

  accepts_nested_attributes_for :line_items,
                                allow_destroy: true,
                                reject_if: :all_blank

  validates :line_items, presence: true
end

The Incoming Params (Critical Detail)

This is the actual shape the controller receives from a Rails nested form / stimulus-rails-nested-form setup:

{
  "invoice" => {
    "date" => "2026-01-11",
    "due_date" => "2026-01-12",
    "client_id" => "123",
    "line_items_attributes" => {
      "0" => {
        "description" => "Web Development",
        "quantity" => "10",
        "unit_price" => "150"
      },
      "1" => {
        "description" => "UI Design",
        "quantity" => "5",
        "unit_price" => "200"
      }
    }
  }
}

⚠️ Important:
line_items_attributes is not an array. It is a hash keyed by dynamic numeric strings ("0", "1", …).

This distinction is the root cause of the bug.

Step 1: Working Version with `require/permit`

def invoice_params
  params.require(:invoice).permit(
    :date,
    :due_date,
    :client_id,
    line_items_attributes: [:description, :quantity, :unit_price, :_destroy]
  )
end

With permit, nested attributes were assigned correctly and validation passed.

Step 2: Switching to `expect` (Unexpected Validation Failure)

def invoice_params
  params.expect(
    invoice: [
      :date,
      :due_date,
      :client_id,
      line_items_attributes: [:description, :quantity, :unit_price, :_destroy]
    ]
  )
end

No error was raised by strong parameters, but line_items_attributes was filtered out.

As a result:

no line items were assigned
validates :line_items, presence: true failed
the invoice was not persisted

Inspecting the result:

invoice_params[:line_items_attributes]
# => #<ActionController::Parameters {} permitted: true>

Why This Happens

This declaration:

line_items_attributes: [:description, :quantity, :unit_price]

means:

“line_items_attributes is a single nested hash with these keys.”

But the incoming data is:

line_items_attributes: {
  "0" => { ... },
  "1" => { ... }
}

That is a collection represented as an indexed hash, not a single hash.

params.expect enforces structure strictly. When the shape does not match, nested attributes are silently dropped.

The Fix: Double Brackets

To express “a collection of nested hashes,” you must use double brackets:

def invoice_params
  params.expect(
    invoice: [
      :date,
      :due_date,
      :client_id,
      line_items_attributes: [[
        :id,
        :description,
        :quantity,
        :unit_price,
        :_destroy
      ]]
    ]
  )
end

What This Means

Inner array → permitted keys for each line item
Outer array → indicates a repeated / collection-like structure

This matches both:

indexed hashes ("0" => {...})
arrays of hashes ([{...}, {...}])

Verified by Request Spec

expect {
  post invoices_path, params: valid_params
}.to not_change(Invoice, :count)
   .and change(LineItem, :count).by(0)

# After fix:
expect {
  post invoices_path, params: valid_params
}.to change(Invoice, :count).by(1)
 .and change(LineItem, :count).by(2)

Mental Model for `expect`

Incoming shape	`expect` declaration
Single nested hash	`line_items_attributes: [:description]`
Indexed hash (`"0" => {...}`)	`line_items_attributes: [[:description]]`
Array of hashes	`line_items_attributes: [[:description]]`

If nested records disappear or validations fail unexpectedly, inspect the shape, not the values.

A Note on RuboCop and `Rails/StrongParametersExpect`

RuboCop often triggers this issue.

The Rails/StrongParametersExpect cop encourages replacing:

params.require(:invoice).permit(...)

with:

params.expect(invoice: [...])

The intent is good: expect makes parameter structure explicit.

However, the cop does not account for how Rails nested forms commonly submit *_attributes—as indexed hashes with dynamic keys. A naïve rewrite is not behavior-preserving.

Practical Guidance

Always verify nested attribute shapes when adopting expect
For has_many nested attributes, use [[...]]
If a controller handles complex or highly dynamic params, it is reasonable to:
- keep require/permit, or
- locally disable Rails/StrongParametersExpect

RuboCop enforces consistency, not correctness.

Key Takeaways

Rails nested forms commonly submit *_attributes as indexed hashes
params.expect is stricter than permit and requires explicit structure
Use [[...]] for has_many nested attributes
Validation failures may be the only symptom
Request specs are essential when changing strong parameter handling

Final Thought

This bug is subtle, silent at the strong-parameter layer, and easy to ship if you rely only on manual testing. If you are migrating to params.expect in Rails 8, nested attributes deserve special attention.

If this saved you time—or cost you some before you found it—you’re not alone.

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

Olumuyiwa Osiname — Sat, 30 Nov 2024 01:27:24 +0000

1. Avoid N+1 Queries with `includes`

N+1 query problem occurs when loading associated records in a loop, triggering a query for each associated record. We can solve this by simply preloading associations with includes.

# Bad: Triggers a query for each user
users = User.all
users.each do |user|
  puts user.posts.count
end
# SELECT * FROM users;
# SELECT COUNT(*) FROM posts WHERE user_id = ... (for each user 😢)

# Good: Preloads the association
users = User.includes(:posts)
users.each do |user|
  puts user.posts.size
end
# SELECT * FROM users;
# SELECT posts.* FROM posts WHERE user_id IN (...); (1 query 😄)

2. Use `pluck` to Fetch Specific Columns

Sometimes we are only interested in specific columns when retrieving a record. Using SQL we would normally SELECT email FROM users WHERE active = TRUE but for some reason we hardly do that when using Active Record.
We can Use pluck to efficiently retrieve specific columns with Active Record.

# Bad: Loads full User objects into memory
emails = User.where(active: true).map(&:email)

# Good: Fetches only the required data
emails = User.where(active: true).pluck(:email)
# SELECT "users"."email" FROM "users" WHERE "users"."active" = TRUE

3. Using Range Syntax

Filter records by date using Rails' range syntax or SQL-like conditions.

posts = Post.where(created_at: ...7.days.ago) 
# Generated SQL: # SELECT "posts".* FROM "posts" WHERE "posts"."created_at" < '2024-11-23 00:00:00'

4. Avoid double negations

For example use present? Instead of !blank?

# Bad: Double negation makes code harder to read 😕 
puts "Name is present" if !user.name.blank? 

# Good: Use `present?` for clarity 👍 
puts "Name is present" if user.name.present?

5. Avoid loading Records when you don't have to.

You can Optimize using exists? Instead of Loading Records

# Bad: Loads full records into memory 😕 
if User.where(email: "test@example.com").first   

# Good: Use `exists?` to avoid loading objects 👍 
if User.exists?(email: "test@example.com")

6. Use `with_options` for DRY Validations

You can group common validations together in your model. I actually do this a lot for validations that I expect to evolve together

# Bad: Repeating validation options 😕 
class Variant < ApplicationRecord   
  validates :price, numericality: { greater_than_or_equal_to: 0 }
  validates :msrp, numericality: { greater_than_or_equal_to: 0 }
end

# Good: Use `with_options` for grouping 👍 
class Variant < ApplicationRecord   
  with_options numericality: { greater_than_or_equal_to: 0 } do
    validates :price
    validates :msrp
  end
end

7. Using `pluck` with a Ruby Hash

caveat: This requires 'active_support/core_ext/hash'

# Example 
users = [{id: 1}, {id: 2}]

# Instead of 
users.map { |user| user[:id] }
#=> [1, 2]

# We could simply
users.pluck(:id) #=> [1, 2]

8. Memoizing Associations with `has_one`

Avoid repeatedly triggering queries for calculated associations by using has_one.

# Bad: Runs a query every time 
class User < ApplicationRecord
  has_many :subscriptions

  def active_subscription
    subscriptions.where(active: true).first
  end
end

# Good: Use `has_one` for efficient association caching

class User < ApplicationRecord
  has_many :subscriptions
  has_one :active_subscription, -> { where(active: true) }, class_name: "Subscription" 
end

[Boost]

Olumuyiwa Osiname — Sat, 30 Nov 2024 01:25:46 +0000

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

Olumuyiwa Osiname ・ Nov 30

#ruby #rails #cleancode

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

Olumuyiwa Osiname — Sat, 30 Nov 2024 01:23:24 +0000

1. Avoid N+1 Queries with `includes`

N+1 query problem occurs when loading associated records in a loop, triggering a query for each associated record. We can solve this by simply preloading associations with includes.

# Bad: Triggers a query for each user
users = User.all
users.each do |user|
  puts user.posts.count
end
# SELECT * FROM users;
# SELECT COUNT(*) FROM posts WHERE user_id = ... (for each user 😢)

# Good: Preloads the association
users = User.includes(:posts)
users.each do |user|
  puts user.posts.size
end
# SELECT * FROM users;
# SELECT posts.* FROM posts WHERE user_id IN (...); (1 query 😄)

2. Use `pluck` to Fetch Specific Columns

# Bad: Loads full User objects into memory
emails = User.where(active: true).map(&:email)

# Good: Fetches only the required data
emails = User.where(active: true).pluck(:email)
# SELECT "users"."email" FROM "users" WHERE "users"."active" = TRUE

3. Using Range Syntax

Filter records by date using Rails' range syntax or SQL-like conditions.

posts = Post.where(created_at: ...7.days.ago) 
# Generated SQL: # SELECT "posts".* FROM "posts" WHERE "posts"."created_at" < '2024-11-23 00:00:00'

4. Avoid double negations

For example use present? Instead of !blank?

# Bad: Double negation makes code harder to read 😕 
puts "Name is present" if !user.name.blank? 

# Good: Use `present?` for clarity 👍 
puts "Name is present" if user.name.present?

5. Avoid loading Records when you don't have to.

You can Optimize using exists? Instead of Loading Records

# Bad: Loads full records into memory 😕 
if User.where(email: "test@example.com").first   

# Good: Use `exists?` to avoid loading objects 👍 
if User.exists?(email: "test@example.com")

6. Use `with_options` for DRY Validations

You can group common validations together in your model. I actually do this a lot for validations that I expect to evolve together

# Bad: Repeating validation options 😕 
class Variant < ApplicationRecord   
  validates :price, numericality: { greater_than_or_equal_to: 0 }
  validates :msrp, numericality: { greater_than_or_equal_to: 0 }
end

# Good: Use `with_options` for grouping 👍 
class Variant < ApplicationRecord   
  with_options numericality: { greater_than_or_equal_to: 0 } do
    validates :price
    validates :msrp
  end
end

7. Using `pluck` with a Ruby Hash

caveat: This requires 'active_support/core_ext/hash'

# Example 
users = [{id: 1}, {id: 2}]

# Instead of 
users.map { |user| user[:id] }
#=> [1, 2]

# We could simply
users.pluck(:id) #=> [1, 2]

8. Memoizing Associations with `has_one`

Avoid repeatedly triggering queries for calculated associations by using has_one.

# Bad: Runs a query every time 
class User < ApplicationRecord
  has_many :subscriptions

  def active_subscription
    subscriptions.where(active: true).first
  end
end

# Good: Use `has_one` for efficient association caching

class User < ApplicationRecord
  has_many :subscriptions
  has_one :active_subscription, -> { where(active: true) }, class_name: "Subscription" 
end

Deploy Rails App from Github to AWS Elastic Beanstalk

Olumuyiwa Osiname — Thu, 17 Sep 2020 17:00:59 +0000

I have mostly always deployed my Rails and Express applications to Heroku but for my new project I wanted to try something different, so I decided to deploy to Elastic Beanstalk.

For this tutorial we're going to need an aws account so head on to amazon and create one if you don't and if you do, login.

Setup rails App

Let's quickly setup our small rails app. Because I am lazy, this is going to be a rails API, we would be using postgres as our database.

Note: You can skip to setup database config section of this part if you already have your rails app created.

Create application

Create a new rails app using

rails new tuts-api --api --database=postgresql

cd tuts-api

let's generate a Post scaffold

rails g scaffold Post

This should generate the following

In create_posts migration file add the following

t.string :title
t.string :description

Run migration

setup db and run migration

rails db:create && rails db:migrate

In your posts_controller, change

def post_params
  params.fetch(:post, {}).permit(:title, :description)
end

def post_params
  params.require(:post).permit(:title, :description)
end

Setup database.yml config

Go over to our local environment and head over to our database.yml file

Change the production section to look like this.

Github

Add Commit and push to Github(you should create a repo and set it as remote, this is beyond the scope of this tutorial, You can find a link to my github repo at the bottom)

We're done with Rails part for now.

Create Elastic beanstalk application

Now go to your aws console

Click on create a new application

Enter application name
Go to Platform section, select Ruby as platform and platform branch (your ruby version)
Click on configure more options

Setup environment variables

In software section, click Edit.
Scroll down to Environment properties
Set RAILS_ENV as production
Go to your rails app on your laptop and generate a secret using rake secret on your terminal

Copy the value and set it as SECRET_KEY_BASE in the environment properties

Save

Add Postgres database

Next we'll configure a database

Scroll down to database section and click on Edit
Select postgres as database engine
set database username and password, then save

Now we click on create app to create our application. This will create an EC2 instance, RDS instance and other things for us. This will take about 10 minutes so let's quickly take a drink break, we deserve it.

OK! Our application and environment should be done by now, let's link our github repo to our application environment

Deploy with github

Navigate to codepipeline service and create a new pipeline
Set Pipeline name and then Next

Select Github as source provider and connect your github account. Select your repository and preferred branch and then Next. (Skip the build stage.)

Select AWS Elastic Beanstalk as Deploy provider, select your application name and application environment like so

Click on Next and then Create Pipeline. This will deploy our github source code to our application environment and also ensure that subsequent commits to master are deployed as well.

You can navigate back to your application to get your application url and test using postman or curl.

You can find my source code here

DEV Community: Olumuyiwa Osiname

Rails 8 Strong Parameters: The Double-Bracket Fix for Nested Attributes

The Problem: Invoices Failed Validation After Switching to expect

The Setup

The Incoming Params (Critical Detail)

Step 1: Working Version with require/permit

Step 2: Switching to expect (Unexpected Validation Failure)

Why This Happens

The Fix: Double Brackets

What This Means

Verified by Request Spec

Mental Model for expect

A Note on RuboCop and Rails/StrongParametersExpect

Practical Guidance

Key Takeaways

Final Thought

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

1. Avoid N+1 Queries with includes

2. Use pluck to Fetch Specific Columns

3. Using Range Syntax

4. Avoid double negations

5. Avoid loading Records when you don't have to.

6. Use with_options for DRY Validations

7. Using pluck with a Ruby Hash

8. Memoizing Associations with has_one

[Boost]

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

Olumuyiwa Osiname ・ Nov 30

Mastering Rails and Ruby: A Collection of Practical Tips for Cleaner Code

1. Avoid N+1 Queries with includes

2. Use pluck to Fetch Specific Columns

3. Using Range Syntax

4. Avoid double negations

5. Avoid loading Records when you don't have to.

6. Use with_options for DRY Validations

7. Using pluck with a Ruby Hash

8. Memoizing Associations with has_one

Deploy Rails App from Github to AWS Elastic Beanstalk

Setup rails App

Create application

Run migration

Setup database.yml config

Github

Create Elastic beanstalk application

Setup environment variables

Add Postgres database

Deploy with github

The Problem: Invoices Failed Validation After Switching to `expect`

Step 1: Working Version with `require/permit`

Step 2: Switching to `expect` (Unexpected Validation Failure)

Mental Model for `expect`

A Note on RuboCop and `Rails/StrongParametersExpect`

1. Avoid N+1 Queries with `includes`

2. Use `pluck` to Fetch Specific Columns

6. Use `with_options` for DRY Validations

7. Using `pluck` with a Ruby Hash

8. Memoizing Associations with `has_one`

1. Avoid N+1 Queries with `includes`

2. Use `pluck` to Fetch Specific Columns

6. Use `with_options` for DRY Validations

7. Using `pluck` with a Ruby Hash

8. Memoizing Associations with `has_one`