Почему шаблон cancelledPromise считается лучше, чем «антишаблон» isMounted() в React?

Давайте представим, что действие, которое вызовет будущий вызов setState, выполняет много вычислений или выполняет множество сетевых запросов. Все эти ресурсы будут использованы, а затем когда-нибудь в будущем, когда промис разрешится, он поймет, что вся работа не нужна, так как пользователь уже покинул эту часть страницы, и вся работа будет отброшена. Это плохо для производительности и использования сети/памяти, особенно если у вас есть много элементов, которые появляются и исчезают. Если вы выберете вариант 3, только небольшое количество ресурсов будет потрачено впустую, пока не будет достигнута следующая точка остановки и ресурсы не будут освобождены. Я предполагаю, что они удалили 1) чтобы заставить кодировщиков использовать 3) и предложили 2) для случаев, когда миграция невозможна/сложна.

Компонентный метод isMounted устарел. Его больше нельзя использовать в React 16.

Встроенного состояния _isMounted нет, оно должно определяться пользователем в хуках жизненного цикла компонента. В какой-то степени это вопрос предпочтений. Проблема в том, что для доступа к this._isMounted требуется, чтобы цепочка обещаний была связана с экземпляром компонента.

Это не проблема для отменяемых обещаний. Более того, этот шаблон позволяет фактически отменить асинхронный процесс, например. Axios фактически отменяет запрос XHR во время отмены. Тем не менее, чтобы это работало, требуется, чтобы вся цепочка обещаний знала об отмене. Это может быть утомительно, так как отмена не поддерживается в собственных промисах, включая async..await.

Наблюдаемые объекты предоставляют еще более мощные способы управления выполнением. Есть единственная точка (подписка), которая способна отменить всю цепочку, вызвав функцию отписки:

const unsubscribe = fetchData()
.mergeMap(asynchronousProcessing)
.mergeMap(yetAnotherAsynchronousProcessing)
.subscribe(data => this.setState(data));

Ключевым элементом здесь является то, что if (this.isMounted()) { setState(...) } является антипаттерном в целом. Это может привести к подавлению полезных предупреждений, поэтому к его появлению следует относиться с подозрением, поскольку в большинстве случаев оно представляет собой возможность скрыть реальные проблемы. Таким образом, даже в тех случаях, когда его поведение функционально такое же, как и у какого-либо другого подхода, этот другой подход предпочтительнее.

В случае вызовов API вполне разумно игнорировать результаты промиса, потому что они больше не актуальны. Использование отмененного обещания синтаксически и семантически связывает логику того, следует ли игнорировать результат, конкретно с вызовом API, что предотвращает любую возможность того, что будущие разработчики случайно используют код в другом контексте и потенциально подавляют значимые предупреждения.

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