Я тоже столкнулся с этой странной ошибкой сегодня утром.Я работаю в режиме нативной поддержки с клиентом Expo для приложения, которое создаю с помощью популярного стека MERN (mongoDB, Express, React Native и Node.js).Я упоминаю, что, поскольку я много использую, я имею в виду МНОГО консольных журналов в бэкэнде, и до сих пор это не вызывало у меня никаких проблем.Так что в моем случае я не был уверен, произошла ли эта ошибка от какого-либо файла console.log, который я использовал.Я проверил трассировку стека экспо-отладчика в консоли (в порту 19001), потому что красный экран не предоставляет много информации о происхождении ошибки (много <unknown>
вместо функций), и я увидел, что в нем есть что-тоделать с моими функциями действий и полезной нагрузкой, которую я отправлял своему редуктору, когда выполнял определенное действие, которое связывалось с бэкэндом.Ответ бэкэнда был отформатирован так:
payload: {
config: {
.
.
.
}
data: { the only part that i needed... }
headers: {
.
.
.
}
..other stuff from the response..
Выше заметить особо нечего, но это:
Фактический выигрыш, который меня интересовал, находится под ключом реквизита data
ибыло единственное, что мне нужно из ответа.НО, в своем невежестве я отправлял все на мой редуктор.Так что я говорю, что я посылал действительно большой object
как payload
, и мне нужна была только его часть.Поэтому, когда я произвел некоторую деструктуризацию и сохранил упомянутый выше data
, ошибка исчезла.
В заключение, для других, которые могут наткнуться на эту «ошибку», которая на самом деле не является ошибкой, bc приложение не аварийно завершает работу или что-то еще, так как вы можете закрыть окно и приложение запускается, когдаВы делаете выборку с сервера, убедитесь, что у вас есть только data
, а не весь объект response
вместе с мета из вызова.Кажется, что redux-logger
выбрасывает этот bc, ему не нравится его структура.
Надеюсь, это поможет и вам.