да я пока пойду потыкаю иначе вряд ли пойму проблему ререндеров

Combine не о ререндерах

а зачем если в компоненте можно вызвать list, id и делать list[id]?

типа просто держать логику вне компонента?

Да

Логика внутри компонента крайне сложно тестируется и разрабатывается

Встречный вопрос: "Зачем редкасу селекторы?"

Посыл вот в чем.
1. Имея все состояние в одной "куске" - необходимо дать возможность нарезать кусок на более мелкие детали.
2. Имея состояние в разных "кусках" - необходимо дать возможность как нарезать "куски" на более мелкие, так и клеить их в более крупные.

Комбайн - это базовая необходимая возможность соединять сторы в один стор на уровне стейт менеджера или его библиотек (да да, из библиотеки ты можешь юзать стор - который является результатом соединения n количества сторов и происхождение стора не будет важно для тебя как для юзера). Условно те же сторы у эффекта - можно принять за результат комбайна. Практическое применение сейчас думаю подскажут

а есть ли кейсы когда в combine хранится что то такое что стоит тестировать?

Ну и дополнительно, компонент будет обновляться при любом обновлении списка.
А с комбайном, только при обновлении выделенного

Не в комбайн, а вообще любую бизнес логику.
Ты же складываешь из операторов эффектора определенную логику. Вот ее и тестировать. Еще и без участия реакта

ну типа если компонент рендерит эл-т из списка то через RTL проверяется что в dom именно он.

Это прям плохие тесты)

разве? а какие хорошие?)

Которые не знают о внутреннем устройстве компонентов

useStoreMap даёт же схожее поведение?

Да

не очень понял как гарантировать что компонент покажет то что мне нужно без RTL

RTL это что? RightToLeft?

testing library

Скрин сделать