Collections and iteration

C# collections are the same shapes you know from JS, with explicit types and interface-first return types. Learn the three you’ll touch most and the rest follow.

var numbers = new List<int> { 1, 2, 3 };                   // a JS array
var byKey = new Dictionary<string, int> { ["a"] = 1 };      // a JS Map
var unique = new HashSet<string> { "a", "b" };              // a JS Set

numbers.Add(4);                 // numbers.push(4)
byKey["b"] = 2;                 // byKey.set("b", 2)
bool has = unique.Contains("a");// unique.has("a")

The difference from JS is that the element type is part of the type: List<int> is a list of ints and nothing else can go in. That <T> is a generic type parameter, the same idea as TS Array<T> or Map<K, V>, and it’s enforced by the compiler.

Iteration is foreach, which is for...of.

foreach (var n in numbers)          // for (const n of numbers)
{
    Console.WriteLine(n);
}

foreach (var (key, value) in byKey) // destructuring a Map's entries
{
    Console.WriteLine($"{key}={value}");
}

Now the Fusion habit that surprises TS developers: methods usually return the interface, not the concrete collection. You’ll see IReadOnlyList<T>, IReadOnlySet<T>, and IEnumerable<T> on return types far more than List<T>.

public async Task<IReadOnlySet<string>> GetDecidedFlightIdentities()
{
    var keys = await _dbContext.FlightDisruptionCostCalcs
        .Select(x => x.EjdpUniqueFlightKey)
        .ToListAsync();
    return keys.ToHashSet(StringComparer.OrdinalIgnoreCase);
}

The method builds a HashSet internally but returns IReadOnlySet<string>. The caller can enumerate it and check membership, but can’t add or remove, so the store’s data can’t be mutated from outside. This is “program to the interface”: expose the smallest contract that does the job.