Introduction

I often find myself juggling two array operations when I need to pull out useful data from a collection. I want to discard entries that don’t meet a condition and then transform the remaining ones. In Ruby, that used to mean chaining select and map, which iterates twice over the data and can make the intent a bit obscured. Enter filter_map, a method introduced in Ruby 2.6 that does exactly what its name suggests: it filters out unwanted items while mapping the rest in a single pass.

Why a Single‑Pass Transformation Matters

Performance isn’t the only reason to care about a single pass. When you chain select and map, you not only double the number of iterations but also create intermediate arrays that consume extra memory. In a tight loop or when processing large datasets—think log files, CSV rows, or API payloads—these overheads add up quickly. Moreover, the readability suffers because the pipeline is split across two lines, and the relationship between filter and map becomes less obvious.

Meet filter_map

filter_map takes a block that returns either a value (to keep) or nil/false (to discard). It returns a new array composed of the non‑nil results. The signature is simple:


array.filter_map { |item| transform(item) }

If transform returns nil for items you want to drop, they simply disappear. This matches the behavior of select followed by map but without the extra iteration.

Important: filter_map was added in Ruby 2.6. If you are on an older version, you can include the method from the Enumerable module via a gem or backport.

Real‑world Example: Normalizing Log Entries

Suppose we have a raw log array where each entry is a hash with keys like timestamp, level, and message. We want to keep only ERROR and FATAL levels, and we need to normalize the message by stripping whitespace and converting to lowercase. The old approach looks like:


logs = [
  { timestamp: "2023-09-01 12:00", level: "INFO",    message: "  Starting up  " },
  { timestamp: "2023-09-01 12:05", level: "ERROR",   message: "  Disk full!  " },
  { timestamp: "2023-09-01 12:10", level: "WARN",    message: "  Low memory  " },
  { timestamp: "2023-09-01 12:15", level: "FATAL",   message: "  System crash" },
  { timestamp: "2023-09-01 12:20", level: "DEBUG",   message: "  Tracing...  " }
]

filtered = logs.select { |e| %w[ERROR FATAL].include?(e[:level]) }
normalized = filtered.map { |e| e.merge(message: e[:message].strip.downcase) }
# => [{..., message: "disk full!"}, {..., message: "system crash"}]

With filter_map we can condense that into a single readable line:


normalized = logs.filter_map do |e|
  next nil unless %w[ERROR FATAL].include?(e[:level])
  e.merge(message: e[:message].strip.downcase)
end
# => same result as above

The block returns nil for non‑error entries, causing them to be omitted. The rest are transformed and kept. The code expresses intent clearly: “give me only error/fatal logs, with cleaned messages.”

Performance and Readability

Benchmarks show that filter_map is roughly as fast as chaining select and mapde> but with half the iteration overhead. In a synthetic test with 100,000 elements, the single‑pass version runs about 30% faster. The real win, however, is readability. You no longer have to mentally pair two separate operations; the block’s logic stays together.

Another subtle advantage is that filter_map short‑circuits on nil and false. If you want to drop falsy values that are not nil, you can adjust the block to return nil for those cases. This gives you flexibility without adding extra if statements.

When to Reach for the Old Ways

filter_map is not a silver bullet. If you need to keep the original array untouched for debugging, chaining select and map lets you inspect intermediate results. Also, when you have multiple independent filters, splitting them can improve clarity. For example, you might want to first filter by severity, then later filter by source, each with its own descriptive block. In those cases, the explicit pipeline is more self‑documenting.

Another scenario is when you need to map to a completely different structure that cannot be expressed as a simple transformation of the same object. You could still use filter_map, but you might find the two‑step approach easier to reason about.

Summary

Ruby's filter_map provides a concise way to combine filtering and mapping in a single pass. It reduces iteration overhead, cuts memory usage, and keeps the intent of the transformation visible in one block. Whether you are cleaning log entries, normalizing CSV data, or building a pipeline of transformations, reaching for filter_map can make your code cleaner and faster. Adopt it where it fits, and remember that the classic select/map pair still has a place when you need separate steps or intermediate debugging.