Question 1

What does it mean that an Iterable is lazy in Dart? What bugs does it cause?

Accepted Answer

Start with the mechanism: map, where, expand, take compute nothing immediately — they return an object that merely knows how to compute; the code runs on a terminal operation such as for-in, toList(), first or length. Then give two concrete bugs. First: side effects vanish — users.map((u) => log(u)); prints nothing because nobody iterates; use forEach or a plain for loop for side effects. Second: the same chain executes twice — final active = users.where(expensive); active.length; active.first; calls the predicate again, and if the source changed in between the two reads can disagree. State the fix in one sentence: call toList() when the result will be read more than once. Finally give the other side — laziness is not always bad: on a large list where(...).first does not scan everything and allocates no intermediate list. That balance lifts the answer to senior level.

Question 2

How do you choose between List, Set and Map? What is the performance difference?

Accepted Answer

Justify the choice by the operation profile. List when order matters and you need index access; note that contains is O(n). Set when you need uniqueness; contains, add and remove are amortised O(1), but there is no positional index (the default LinkedHashSet still preserves insertion order). Map for lookup by key, with the same O(1) profile. Give a concrete example: calling list.contains(x) inside a loop over 10,000 elements is O(n²) — I build final index = list.toSet(); (or index into a Map) first and check against that. An important nuance: Set membership and Map keys rely on == and hashCode, so if your class does not override them correctly two "equal" objects appear twice in a set. Finish with immutability: wrapping a shared collection in List.unmodifiable or const, especially inside state objects, prevents accidental mutation.

Question 3

Why do you use collection-if, collection-for and the spread operators?

Accepted Answer

Answer with practical benefits. Readability: I build the list as a single expression — the intermediate final result = <String>[]; and the imperative blocks that fill it disappear. Null safety: ...?maybeList removes the if (x != null) result.addAll(x!) dance and the ! in it. const compatibility: a declarative literal can be const when all elements are constant; an imperatively built list never can — which in Flutter means saved rebuilds. Conditional elements: [if (isAdmin) 'delete' else 'request'] — if/else works as an expression. Showing the same function as a 12-line imperative version and a 5-line declarative one helps. Add the nuance that deeply nested collection-for chains hurt readability, and there I extract a normal method — i.e. I do not apply the rule blindly.

Question 4

How would you optimise a heavy transformation chain over a large collection?

Accepted Answer

Start with measurement — before claiming an optimisation, show which step is expensive using the DevTools CPU profiler or a simple Stopwatch. Then list the typical fixes. Remove intermediate materialisation: in where(...).toList().map(...).toList() the middle toList() is a wasted allocation; a lazy chain iterated once is cheaper. Remove repeated iteration: conversely, if the result is read in several places, materialise once with toList(). Make lookups O(1): replace list.contains or firstWhere inside a loop with a prebuilt Set/Map index. Short-circuit: answer "is there any?" with any(...) rather than where(...).isNotEmpty. Cut early: placing take(n) after the filter lets the lazy chain compute only as many elements as needed. Finally tie it to Flutter: heavy parsing or sorting over thousands of items on the UI thread drops frames — I move that work to compute() (an isolate), because Dart is single-threaded and a long synchronous loop overruns the frame budget.

Construction	Result	What is allowed
`[1, 2, 3]`	Growable list	`add`, `remove`, `length = n`
`List.filled(3, 0)`	Fixed-length list	Elements can be changed, `add` throws `UnsupportedError`
`List.unmodifiable([1, 2])`	Read-only view	No mutation at all
`const [1, 2]`	Canonicalised immutable list	No mutation at all
`someIterable.toList()`	New growable list	Full mutation

Method	Returns	Lazy?	Typical use
`map`	`Iterable<R>`	Yes	Transformation
`where`	`Iterable<T>`	Yes	Filtering
`expand`	`Iterable<R>`	Yes	flatMap — flattening nested lists
`fold`	A single value	No	Aggregation with a seed value
`reduce`	A single value	No	Aggregating a non-empty collection
`any` / `every`	`bool`	No (short-circuits)	Predicate checks
`toList` / `toSet`	A collection	No	Materialising the result

Collections and Iterable

📚 Sources and documentation