const Component = (props) => {
   const state = useMappedState(getStateWithMySelector);

   return (<></>)
}

const Component = (props) => {
   const todo = useMappedState(useCallback(
     state => state.todos.get(props.id),
     [props.id],
   ));

   return (<></>)
}

const Component = (props) => {
  const dispatch = useDispatch();

  const handleClose = useCallback((event) => {
    dispatch(tryHideSnackBar({ snackId: props.id }));
  }, [props.id]);

   return (<></>)
}

Потому что хуки заменяют в том числе и connect.

Смешно это ваше "формализм", "матан".
REST скорее ближе к натуральным языкам — убогое, сирое, но в некоторых вещах работает лучше остального (stateless), а еще его все понимают (индустриальный стандарт).
Не стоит натягивать REST везде

Нет, он даёт использовать. Просто авторенейма нет

Не совсем. При компиляции вы точно получите ошибку, а авто-ренейм пока не реализован скорее специально, но его можно реализовать. Это конечно же доступно, только если вы не балуетесь форсированными кастами.

В typescript для этого есть keyof

• Обновлений практически нет — пример: всякие редакторы (редактор слайдов, графиков и т.д.) — необходимые ресурсы загружаются при инициализации; Перезагрузка не нужна.
• Обновления происходят редко — пример: многие новостные порталы. Обновление делегируется браузеру (F5)
• Предполагается короткое время жизни UI — пример: данные подгружаются в попапе, который будет закрыт через 10-30 секунд (попап сохранения в Google Drive). Перезагрузка не нужна.
• Загрузка происходит слишком долго — пример: генерация контента на лету. Нужно не debounce делать, а показывать, что что-то грузится очень долго и блочить возможность повторных попыток. Натягивать это на стрим — можно, но не нужно
• Общая несовместимость концепта с перезагрузкой данных — опять же, какой угодно редактор, который не предполагает shared editing.

Из диалога с вами ретируюсь, дальше без меня.

В вашем примере сломается и Фьюча, а вот Обсервабл как раз легко расширить на такой в ариант

Для использования Обсервабла в качестве Промиса/Фьючи никаких особых знаний о Скедулере иметь не нужно

примените оператор first (хоть прям по месту использования обсервабла).

Используемый код получит Observable, который в случае возврата лишь одного значения эквивалентен Promise/Future. Не пишите чепухи, Observable — это обобщение любых асинхронных источников данных

А код семантически получится эквивалентный Флутеру, никакой дополнительной когнитивной нагрузки rxJS от вас не потребует (если вам от неё нужно только то, что нужно от Флутера).

Если вам не нужен FRP

не нужно пытаться убеждать себя, что и другим оно не нужно.

Вам явно не стоит хвастаться своей практикой.

• Да, смартфон часто находится под рукой, но не у всех и не всегда;
• На пульте ты кликаешь «увеличить громкость», а на смартфоне ты ждешь, пока прогрузится софтина для управления;
• У некоторых людей нет смартфоно-зависимости и они не знают, где их смартфон (или он лежит в четко отведенном месте);
• А еще смартфон может лежать на зарядке, которая может находиться вдали от пользователя;
• Завязывать все на одно хрупкое устройство — ну так себе идея;
• У многих смартфоны дешевого класса (ибо нах?) и они работают не очень хорошо для любых целей кроме «позвонить».

Именно поэтому при серьезном рефакторинге лучше сначала дописать недостающие unit-test'ы, а только потом вносить изменения способные все сломать

проверять значения нужно в другом тесте

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

Ват? Вы тестами собираетесь проверять будущее поведение?