Demian Smith

Люди древности так привязывали метод к контексту. В давние времена не существовало стрелочных функций.

В вашем примере мы передаём функцию this.addFriend в обработчик события addNew. JS так устроен что когда вы передаёте this.addFriend (куда угодно, хоть в обработчик, хоть в переменную), то будет передан только addFriend без this. Bind как раз нужен для того чтоб прибить FriendsContainer к контексту метода addFriend.

В современном мире принято делать так:

class FriendsContainer extends React.Component {
  addFriend = (friend) = >{
    this.setState((state) => ({
      friends: state.friends.concat([friend])
    }))
  }
}

Это по сути тот же bind, только без лишних телодвижений.

Вот статья как раз об этом https://tylermcginnis.com/react-router-protected-r...

Делаете компонент PrivateRoute (в вашем случае его можно назвать по-другому, например PrivatePageRoute) и в нём проверяете, можно или нельзя. И если нельзя, то показываете сообщение об ошибке или выводите <Redirect to={...}> чтоб редиректнуть куда надо.

То что вас интересует, в народе называется rehydration и saga не совсем об этом. Будет как гвоздь, микроскопом забитый. Вот подходящая библиотека https://github.com/rt2zz/redux-persist

Или вот этот комментарий от одного из авторов редакса о том как достичь желаемого без библиотеки https://stackoverflow.com/a/35675304/379949

Уберите эту часть

constructor(props: Props) {
    super(props);
  }

Этот код выполняется автоматически в классе React.Component. Его не нужно дублировать.

UPD

А вообще код слегка странный. Я так понимаю что App у вас главный компонент. Предполагаю что он рисуется в файле index.ts. Вашему App точно нужны props? Если нужны, то их нужно передать. Как-то вот так:

<App props={} />

Вам совершенно не нужно тестировать функцию createStore потому что она очень хорошо протестирована создателями библиотеки и прекрасно работает. Вам нет смысла убеждаться что эта функция делает то, что от неё ожидают.

Но есть смысл протестировать свою функцию редьюсера. Это очень легко - достаточно подавать состояние и действие на вход функции редьюсера и проверять какое новое состояние она возвращает.

UPD

Да и в целом, юнит тестирование кода библиотек - это так себе идея. Лучше потратить время на тестирование своего кода.

Очень часто можно увидеть что программисты в рамках тестирования пытаются убедиться что библиотека правильно вызвала их код. Это, по сути, опять же тестирование кода библиотеки. Процесс не только бесполезный, но и вредный. Почему он вредный? Потому что программист занимается дублирование тестов библиотеки, создавая код, не приносящий пользы, но требующего дополнительного времени на поддержку.

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

ReactJS не относится к реактивному программированию. React - это фреймворк представления. И, да, его название может ввести в заблуждения.

За реактивное программирование в JS отвечает библиотека RxJS. И вы правы, примеров в стиле "вот так это делается на jQuery, а вот так это делается на RxJS" вы врядли найдёте. Вообще, если начать набирать в гугле "RxJS vs " то гугл будет подсказывать полную чушь, потому что Rx невозможно сравнить с не-Rx.

Вот неплохая статья, в которой Rx используется, так сказать, по назначению https://habrahabr.ru/company/infopulse/blog/338910/

Не совсем представляю себе что такое AsyncTask, но Слушатель - это шаблон проектирования. А Rx - это парадигма программирования. Сравнивать шаблон и парадигму так же сложно как сравнивать кирпичный дом и деревянную доску. В Rx предусмотрена сущность Subject, которая как раз и представляет поведение шаблона Слушатель.