Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Проблема актуальна только лишь когда ты работаешь с локальным состоянием компонента, если используешь MobX или Redux и там делаешь асинхронные вызовы и изменение стейта, то эта проблема не актуальна.
Я думаю следует на это акцентировать внимание, чтобы паники ни у кого не возникло)
Я думаю следует на это акцентировать внимание, чтобы паники ни у кого не возникло)
Есть некая штука, которая инициирует обработку данных, которые уже ни кому не нужны. Это следствие ошибки в кодинге, приводящей к утечкам памяти или потреблению лишних ресурсов. Реакт в некоторых случаях подсказывает о проблемных местах и спасибо ему за это. Сохранение данных в глобальный стор не устраняет такие ошибки, а лишь усложняет их диагностику.
1) Вэб браузер и вэб приложение на реакте и т.п. это вообще не про экономию ресурсов и памяти.
2) Сами по себе браузеры текут по памяти, вы можете это легко проследить в диспетчере задач. (Пока я писал этот комментарий и больше ничего не делал хром стал кушать + 70 Мб оперативки с того момента, как я открыл диспетчер задач, а открыл я его когда дошел до этого пункта)
3) Если данные «которые уже ни кому не нужны» в текущий момент времени, то они могут быть нужны через минуту или через секунду. Есть разные кейсы, в том числе и кэширование на клиенте ответов от сервера на несколько минут. И пользователю для этого уже будет не обязательно пялится в лоадер.
4) Даже если вы будете перед каждым сохранением данных от АПИ проверять, а есть ли сейчас экраны и компоненты активные которым эти данные нужны или нет:
— Ваш код значительно усложнится и засорится, появится куча возможностей для потенциальных багов, которые вы как раз потом задолбаетесь диагностировать.
— Ваша экономия в пару мегабайт памяти, это просто капля в море и не стоит того того, что ваш код превратится в нечто ужасное и потенциально более забагованное. Как мы все знаем, чем проще код и алгоритм, тем он работает надежнее и отказоутсойчивее.
2) Сами по себе браузеры текут по памяти, вы можете это легко проследить в диспетчере задач. (Пока я писал этот комментарий и больше ничего не делал хром стал кушать + 70 Мб оперативки с того момента, как я открыл диспетчер задач, а открыл я его когда дошел до этого пункта)
3) Если данные «которые уже ни кому не нужны» в текущий момент времени, то они могут быть нужны через минуту или через секунду. Есть разные кейсы, в том числе и кэширование на клиенте ответов от сервера на несколько минут. И пользователю для этого уже будет не обязательно пялится в лоадер.
4) Даже если вы будете перед каждым сохранением данных от АПИ проверять, а есть ли сейчас экраны и компоненты активные которым эти данные нужны или нет:
— Ваш код значительно усложнится и засорится, появится куча возможностей для потенциальных багов, которые вы как раз потом задолбаетесь диагностировать.
— Ваша экономия в пару мегабайт памяти, это просто капля в море и не стоит того того, что ваш код превратится в нечто ужасное и потенциально более забагованное. Как мы все знаем, чем проще код и алгоритм, тем он работает надежнее и отказоутсойчивее.
Программирование это и в самом деле борьба со сложностью. В примере из статьи сложность обусловлена тем, что вызовы await нельзя отменить, прервав выполнение функции, даже если результат нас больше не интересует. Решение задачки «в лоб», расстановкой флажков, может прилично усложнить код. Что в принципе и наблюдаем.
При том, что не нужный нам запрос все равно будет выполнен, создавая нагрузку на сервер и выкачивая лишний трафик. themoviedb штука чужая и бесплатная, но когда речь зайдет про собственный модный бекенд в клауде, то этот незначительный нюанс будет стоить вам вполне конкретных денег. Использование AbortController, как предложено ниже, решит эту проблему, но добавит еще писанины.
Если копнуть глубже, то причина сложности кроется в том, что для эффектов мы часто пытаемся использовать привычные структуры, которые для этого не особо предназначены. Promise в JavaScript является абстракцией над значением (value) — оно либо есть сейчас, либо, может быть, появится потом, — а не процессом получения этого значения. Обещание можно дать, выполнить или зафейлить. Но отменить — нельзя.
Эффекты удобнее строить с помощью того, что можно естественным образом отменять. Например — Observable:
В момент подписки (вызове subscribe()) будет инициирован запрос. Но если компонент начнет размонтироваться, то unsubscribe() все отменит.
При том, что не нужный нам запрос все равно будет выполнен, создавая нагрузку на сервер и выкачивая лишний трафик. themoviedb штука чужая и бесплатная, но когда речь зайдет про собственный модный бекенд в клауде, то этот незначительный нюанс будет стоить вам вполне конкретных денег. Использование AbortController, как предложено ниже, решит эту проблему, но добавит еще писанины.
Если копнуть глубже, то причина сложности кроется в том, что для эффектов мы часто пытаемся использовать привычные структуры, которые для этого не особо предназначены. Promise в JavaScript является абстракцией над значением (value) — оно либо есть сейчас, либо, может быть, появится потом, — а не процессом получения этого значения. Обещание можно дать, выполнить или зафейлить. Но отменить — нельзя.
Эффекты удобнее строить с помощью того, что можно естественным образом отменять. Например — Observable:
import { ajax } from "rxjs/ajax"
...
useEffect(() => {
const subscription = ajax.getJSON(MOVIE_DB_GET).subscribe(setMovie, console.error)
return () => subscription.unsubscribe()
}, []);
В момент подписки (вызове subscribe()) будет инициирован запрос. Но если компонент начнет размонтироваться, то unsubscribe() все отменит.
Ещё раз повторюсь
Далее, открою секрет, когда вы отправили запрос на сервер и потом не дожидаясь ответа отменили его, то все равно сервер уже иницировал тяжелые запросы в базу данных(выполнение которых нельзя отменить, они работают синхронно и не проверяют на каждый тик продолжать или нет), запросы в микросервисы которые выполняют тяжелые вычисления и т.п., всё это уже займет процессорное время на выполнение операций и не важно, нужны ли вам эти данные или уже не нужны.
Так что не стоит питать иллюзий что вы таким образом облегчите жизнь серверу, максимум что вы сделаете — сэкономите немножко трафика на клиенте, но опять же это не оправдано из-за усложнения кодовой базы и провокации потенциальных ошибок на проверки актуальности, а всё это в добавок отнимает дополнительное время и ресурсы на разработку фич и фиксы багов, ресурсы на тестирование сие чуда, менеджмент и т.д и т.п.
Если данные «которые уже ни кому не нужны» в текущий момент времени, то они могут быть нужны через минуту или через секунду. Есть разные кейсы, в том числе и кэширование на клиенте ответов от сервера на несколько минут. И пользователю для этого уже будет не обязательно пялится в лоадер.
Далее, открою секрет, когда вы отправили запрос на сервер и потом не дожидаясь ответа отменили его, то все равно сервер уже иницировал тяжелые запросы в базу данных(выполнение которых нельзя отменить, они работают синхронно и не проверяют на каждый тик продолжать или нет), запросы в микросервисы которые выполняют тяжелые вычисления и т.п., всё это уже займет процессорное время на выполнение операций и не важно, нужны ли вам эти данные или уже не нужны.
Так что не стоит питать иллюзий что вы таким образом облегчите жизнь серверу, максимум что вы сделаете — сэкономите немножко трафика на клиенте, но опять же это не оправдано из-за усложнения кодовой базы и провокации потенциальных ошибок на проверки актуальности, а всё это в добавок отнимает дополнительное время и ресурсы на разработку фич и фиксы багов, ресурсы на тестирование сие чуда, менеджмент и т.д и т.п.
Всегда храню полученные данные с сервера в глобальном хранилище. Если это конечно не часто обновляемая информация. В любом случаем, при развитии проекта придется задействовать полученные данные в разных ветвях дерева компонентов. А так, ты избавляешься от лишнего переписывания.
Можно отменять запрос при unmount: developers.google.com/web/updates/2017/09/abortable-fetch.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ReactJS. Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memo