In Ruby, when do partition and filter_map beat chaining select with reject or map, and which values does filter_map drop?

## Two methods that save a pass Many filtering tasks in Ruby are written as two steps with the same test or a test followed by a transformation. `Enumerable` provides two methods that do these in a single pass: - **`partition`**: split into matches and non-matches. - **`filter_map`**: keep some elements and transform them at the same time. ## `partition` `partition` calls the block for every element and returns an array of **two arrays**: 1. the elements for which the block was **truthy**; 2. all the other elements. The usual idiom destructures it straight away: ```ruby overdue, current = invoices.partition { |i| i.days_late > 30 } ``` Compared with `select` plus `reject`: | | `select` + `reject` | `partition` | |---|---|---| | Passes over the data | two | one | | Block calls per element | two | one | | Risk of tests drifting apart | yes, two copies | no, one test | | Result | two separate arrays | `[truthy_array, falsy_array]` | The single test is the bigger win: when someone later changes "30 days" to "45 days", there is only one place to change. `partition` always returns two arrays, either of which may be empty, and on a `Hash` the elements are `[key, value]` pairs. `partition` splits into exactly two groups. For more than two, grouping by a key is a different method. ## `filter_map` `filter_map` calls the block once per element and returns an array of the block's **truthy results**. It is the combination of `map` and `select` in the order people usually want: ```ruby invoices.filter_map { |i| i.number if i.days_late > 30 } ``` The `if` modifier returns `nil` when the condition fails, and `filter_map` drops that `nil`. It replaces two common chains: - `invoices.select { |i| i.days_late > 30 }.map(&:number)` walks twice and builds an intermediate array. - `invoices.map { |i| i.number if i.days_late > 30 }.compact` builds an array full of `nil`s first. ## The two `filter_map` traps **It drops `false` too.** Anything falsy is removed, and in Ruby that means `nil` and `false`. If the transformation can legitimately produce `false`, for example extracting a boolean `disputed` flag, those results vanish silently. Use `map` followed by `compact`, which removes only `nil`, when `false` must survive. **It keeps block results, not elements.** A block that returns only a condition gives you the condition's values: ```ruby invoices.filter_map { |i| i.days_late > 30 } # => [true, true] ``` That is almost never intended. If the goal is the elements themselves, `select` is the right method; `filter_map` is for when you want something *derived* from each kept element. ## On a `Hash` Both methods come from `Enumerable`, so on a `Hash` they see `[key, value]` pairs and return **arrays**: - `balances.partition { |_customer, days| days > 30 }` returns two arrays of pairs. Mapping each back with `to_h`, as in `.map(&:to_h)`, restores two hashes. - `balances.filter_map { |customer, days| customer if days > 30 }` returns an array of customer names directly, which is often all the reminder job needs. This differs from `Hash`'s own filtering methods, which return a hash; knowing which methods keep the receiver's type and which fall back to `Enumerable`'s arrays avoids surprises when the result is passed on. ## Choosing among the selection methods - Need the matching **elements**: `select` (or `reject` for the rest). - Need **both** groups: `partition`. - Need a **value derived** from each matching element: `filter_map`. - Need the first match only: `find`. All four return arrays except `find`, and all four walk the whole collection except `find`. ## In an interview Explain `partition`'s return shape and destructuring, then `filter_map`'s truthy-results rule. The follow-ups interviewers like are exactly the traps: what happens to `false`, and what a boolean-returning block produces.