`map()` transforms each value emitted by a Reactor `Flux` or `Mono`. Give it a function that accepts one value and returns another; the result remains a `Flux` or `Mono`, but its value type can change. For example, a `Flux<String>` of names can become a `Flux<Player>`. section 11.3.3 section 11.2
@Test
public void map() {
Flux<Player> playerFlux = Flux
.just("Michael Jordan", "Scottie Pippen", "Steve Kerr")
.map(n -> {
String[] split = n.split("\\s");
return new Player(split[0], split[1]);
});
StepVerifier.create(playerFlux)
.expectNext(new Player("Michael", "Jordan"))
.expectNext(new Player("Scottie", "Pippen"))
.expectNext(new Player("Steve", "Kerr"))
.verifyComplete();
}
@Data
private static class Player {
private final String firstName;
private final String lastName;
}
Follow the lambda from each player-name string to its `Player` object. The StepVerifier assertions check the values emitted by the resulting Flux. section 11.3.3
Mapping happens synchronously as each source item is published. If the transformation itself returns a `Mono` or `Flux`, use `flatMap()` to avoid nesting publishers; paired with `subscribeOn()`, it can support asynchronous transformations. section 11.3.3 section 13.1.4
Supply reactive security with user details
A reactive user repository returns `Mono<User>`, while `ReactiveUserDetailsService.findByUsername()` must return `Mono<UserDetails>`. Return `userRepo.findByUsername(username).map(user -> user.toUserDetails())`. If no user matches, the Mono is empty and authentication fails. section 12.5.2
Put saved tacos back into an order
When a repository emits saved `Taco` objects, `.map(taco -> { order.addTaco(taco); return order; })` adds each taco, including its assigned ID, to the order and emits `TacoOrder` rather than `Taco`. The surrounding save operation uses `flatMap()` because its transformation returns a publisher. section 13.1.4
