Challenge 3: remember and key() in a List — Solution

data class Product(val id: Int, val name: String, val price: Double)

@Composable
fun ProductListScreen(products: List<Product>) {
    val sortedProducts = remember(products) { products.sortedBy { it.price } }

    LazyColumn {
        items(sortedProducts, key = { it.id }) { product ->
            Text(text = "${product.name} — $${product.price}")
        }
    }
}

// If remember(products) { ... } were removed (sorting done inline every
// recomposition instead):
// The sortedBy { it.price } call would re-run on EVERY recomposition of
// ProductListScreen, even ones triggered by something completely
// unrelated to the products list (e.g. a parent composable recomposing
// for its own reasons). For a small list this is unnoticeable; for a
// large list, or a sort with a more expensive comparator, this becomes
// real, repeated, wasted CPU work on every single recomposition.
//
// If key = { it.id } were removed (LazyColumn falling back to
// positional identity instead):
// Compose would then track each row by its POSITION in the list rather
// than by product.id. If products were reordered (e.g. after a
// re-sort), Compose could incorrectly treat "the item now at position 2"
// as the SAME logical item as "whatever was previously at position 2" —
// potentially causing incorrect animations, lost per-item UI state (like
// a row's expanded/collapsed state), or visually jarring transitions
// during list updates, even though the underlying DATA itself is
// correct.

Notes:
- remember(products) uses "products" itself as the remember key — a
  DIFFERENT products list reference triggers a fresh sort; the SAME
  reference across recompositions reuses the cached sortedProducts
  without re-sorting.
- key = { it.id } inside items(...) plays the same conceptual role as
  DiffUtil's areItemsTheSame (Course 1, Chapter 5) and React's key prop
  — a stable identity for each row, independent of its current position
  in the list.
- Both techniques address DIFFERENT problems: remember avoids
  recomputing a derived value unnecessarily; key avoids Compose
  misidentifying which row is which across list changes. Using one
  doesn't substitute for the other.