Какой подход к хранению процессов загрузки является предпочтительным?

Question

Можете ли вы помочь решить, какая из архитектур будет лучше (получение списка из API с помощью response-native, реагировать-избыточно, избыточно-преобразовано)

1. пример

// component
componentDidMount() {
	this.props.dispatch(fetchFunction());
}

// thunk action
fetchFunction () {

	dispatch START_LOADING

	return dispatch (
		fetch()
			dispatch SUCCESS_LOADING
	);

}

ИЛИ

2. пример

// component
componentDidMount() {
	this.setState({'loading': true})
	this.props.dispatch(fetchFunction()).finally(
		this.setState({'loading': false})
	);
}

//thunk action
fetchFunction () {

	return dispatch (
		fetch()
			dispatch SUCCESS_LOADING
	);

}

Моя идея о хранении "процесса загрузки" в состоянии локальных компонентов? Каковы плохие и хорошие стороны этого подхода?

как я вижу - пример 2:

Если загрузка занимает больше времени, я могу оставить компонент (он отключается), и я увижу предупреждение - «изменение состояния на отключенном компоненте»

1 пример: Сохраняет много дополнительных данных, которые мне не нужны, в избыточном хранилище (также много данных, которые мне нужно исключить из постоянного хранилища), и, например, если у меня есть компонент продукта интернет-магазина, у меня будет много реквизитов пользовательского интерфейса, хранящихся в redux (например, список из 10 товаров, и у каждого товара есть свои кнопки с состояниями) :( НО мне это нравится, потому что вся логика остается в redux-thunk-actions, и мне не нужно заботиться о компоненте, как продолжить кодирование после отправки, было ли это обещанием или не было примером:

 this.props.dispatch(fetchFunction()).then(() => {});

или просто

 this.props.dispatch(fetchFunction());
 .. some code

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

Answer 1

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

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

Хранение всего в хранилище примитивов также облегчает отладку, потому что вы можете видеть все значения в избыточном наборе ресурсов, а не искать отдельные компоненты, чтобы увидеть их локальное состояние.