Какой смысл использовать Redux-Thunk против обычного асин c кода? [Примеры включены] - PullRequest
Новая
       21

Какой смысл использовать Redux-Thunk против обычного асин c кода? [Примеры включены]

1 голос
/ 23 апреля 2020

Я всегда изо всех сил пытался разобраться с Redux-thunk, так как он действительно не понимает, какой великой цели он служит. Например, вот случайный пример Redux-Thunk, который я нашел на веб-сайте: 

export const addTodo = ({ title, userId }) => {
  return dispatch => {
    dispatch(addTodoStarted());

    axios
      .post(ENDPOINT, {
        title,
        userId,
        completed: false
      })
      .then(res => {
        setTimeout(() => {
          dispatch(addTodoSuccess(res.data));
        }, 2500);
      })
      .catch(err => {
        dispatch(addTodoFailure(err.message));
      });
  };
};

На первый взгляд это просто, addTodo - это функция, которая берет заголовок и userId и возвращает функцию с диспетчеризацией в качестве параметра, который затем использует диспетчеризацию один раз, а затем снова для ответа на запрос HTTP. Поскольку в этом случае используется Redux-Thunk, вы просто должны сделать dispatch(addTodo(x,x));

Почему бы мне просто не сделать что-то подобное? 

function addTodo(dispatch, title,userId){
  dispatch(addTodoStarted());

  axios
    .post(ENDPOINT, {
      title,
      userId,
      completed: false
    })
    .then(res => {
      setTimeout(() => {
        dispatch(addTodoSuccess(res.data));
      }, 2500);
    })
    .catch(err => {
      dispatch(addTodoFailure(err.message));
    });
}

Тогда из любого места я могу просто позвоните addTodo(dispatch, x, x);

Зачем мне использовать пример Redux-Thunk вместо моего собственного?

1 Ответ

0 голосов
/ 23 апреля 2020

Вот несколько моментов, с помощью которых я попытаюсь объяснить, почему go следует использовать с избыточным-thunk.

  1. Его промежуточное ПО, так что он будет делать объект отправки и состояния доступным в каждом действие, которое вы определяете, не прикасаясь к коду компонента.

  2. Когда вы передаете диспетчерскую функцию, которая является либо из реквизита, либо из mapDispatchToProps (response-redux), который создает замыкание. Это закрытие сохраняет память использованной до завершения операции asy c.

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

  4. Если что-то уже доступно и протестировано с большими усилиями и поддержкой сообщества, почему бы не использовать его.

  5. ваш код будет более читабельным и модульным.

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

...