What is the use case for flatMap vs map in kotlin

Question

in https://try.kotlinlang.org/#/Kotlin%20Koans/Collections/FlatMap/Task.kt

it has sample of using flatMap and map

seems both are doing the same thing, is there a sample to show the difference of using flatMap and map?

the data type:

data class Shop(val name: String, val customers: List<Customer>)

data class Customer(val name: String, val city: City, val orders: List<Order>) {
    override fun toString() = "$name from ${city.name}"
}

data class Order(val products: List<Product>, val isDelivered: Boolean)

data class Product(val name: String, val price: Double) {
    override fun toString() = "'$name' for $price"
}

data class City(val name: String) {
    override fun toString() = name
}

the samples:

fun Shop.getCitiesCustomersAreFrom(): Set<City> =
    customers.map { it.city }.toSet()
    // would it be same with customers.flatMap { it.city }.toSet() ?

val Customer.orderedProducts: Set<Product> get() {
    return orders.flatMap { it.products }.toSet()
    // would it be same with return orders.map { it.products }.toSet()
}

Solution 1

Consider the following example: You have a simple data structure Data with a single property of type List.

class Data(val items : List<String>)

val dataObjects = listOf(
    Data(listOf("a", "b", "c")), 
    Data(listOf("1", "2", "3"))
)

flatMap vs. map

With flatMap, you can "flatten" multiple Data::items into one collection as shown with the items variable.

val items: List<String> = dataObjects
    .flatMap { it.items } //[a, b, c, 1, 2, 3]

Using map, on the other hand, simply results in a list of lists.

val items2: List<List<String>> = dataObjects
    .map { it.items } //[[a, b, c], [1, 2, 3]] 

flatten

There's also a flatten extension on Iterable<Iterable<T>> and also Array<Array<T>> which you can use alternatively to flatMap when using those types:

val nestedCollections: List<Int> = 
    listOf(listOf(1,2,3), listOf(5,4,3))
        .flatten() //[1, 2, 3, 5, 4, 3]

Solution 2

There are three functions in play here. map(), flatten(), and flatMap() which is a combination of the first two.

Consider the following example

data class Hero (val name:String)
data class Universe (val heroes: List<Hero>)

val batman = Hero("Bruce Wayne")
val wonderWoman = Hero (name = "Diana Prince")

val mailMan = Hero("Stan Lee")
val deadPool = Hero("Wade Winston Wilson")

val marvel = Universe(listOf(mailMan, deadPool))
val dc = Universe(listOf(batman, wonderWoman))

val allHeroes: List<Universe> = listOf(marvel, dc)

Map

allHeroes.map { it.heroes }

// output: [[Hero(name=Stan Lee), Hero(name=Wade Winston Wilson)], [Hero(name=Bruce Wayne), Hero(name=Diana Prince)]]

Map allows you to access each universe in {allHeroes} and (in this case) return its list of heroes. So the output will be a list containing two lists of heroes, one for each universe. The result is a List>

Flatmap

allHeroes.flatMap { it.heroes } 

// output: [Hero(name=Stan Lee), Hero(name=Wade Winston Wilson), Hero(name=Bruce Wayne), Hero(name=Diana Prince)]

FlatMap allows you to do the same as map, access the two lists of heroes from both universes. But it goes further and flattens the returned list of lists into a single list. The result is a List

Flatten

allHeroes.map { it.heroes }.flatten() 

// output: [Hero(name=Stan Lee), Hero(name=Wade Winston Wilson), Hero(name=Bruce Wayne), Hero(name=Diana Prince)]

This produces the same result as flatMap. So flatMap is a combination of the two functions, map{} and then flatten()

Comments

[IgorGanapolsky]

What is the use of flatten vs flatMap?

[Kristopher Noronha]

Is there any performance difference between .map{ f }.flatten() vs .flatMap{ f } ?

[Scott Driggers]

flatMap(function) is the same as map(function).flatten()

[mochadwi]

cmiiw the former: O(2n) time complexity (doing the first n on .map then .flatten) the latter: O(n) time complexity @KristopherNoronha

[Kristopher Noronha]

@mochadwi I think O notation ignores the constant, so both are O(n) as far as time is concerned... however I suspect memory/temp objects might paint a different story and that's probably the diffrentiating factor when working with large structures.

[mochadwi]

agreed, the actual differentiation factor was the space constraint