Используйте Async с обещанием .then
Привет, после настройки простой асинхронной функции с возвратом обещания, которую я хотел бы использовать, а затем обещание вместо попытки! Но возвращается
await is a reserved word
для второго ожидания в функции.
Я пытался разместить асинхронный возврат, обещая данные! но тоже не работал
async infiniteNotification(page = 1) {
let page = this.state.page;
console.info("^^^^^", page);
let auth_token = await AsyncStorage.getItem(AUTH_TOKEN);
fetch(`/notifications?page=${page}`, {
method: "GET",
headers: {
Accept: "application/json",
"Content-Type": "application/json",
Access: auth_token
},
params: { page }
})
.then(data => data.json())
.then(data => {
var allData = this.state.notifications.concat(data.notifications);
this.setState({
notifications: allData,
page: this.state.page + 1,
});
let auth_token = await AsyncStorage.getItem(AUTH_TOKEN);
fetch("/notifications/mark_as_read", {
method: "POST",
headers: {
Accept: "application/json",
"Content-Type": "application/json",
Access: auth_token
},
body: JSON.stringify({
notification: {
read: true
}
})
}).then(response => {
this.props.changeNotifications();
});
})
.catch(err => {
console.info(err);
});
}
> ожидание — зарезервированное слово (100:25) let auth_token = await AsyncStorage.getItem(AUTH_TOKEN); ^ fetch("/notifications/mark_as_read", {
зачем использовать смесь async await и promise.then? Это похоже на хорошее место, чтобы сделать небольшой рефакторинг, сделать ваши запросы отдельными функциями, дождаться тех, чтобы вы могли удалить обратные вызовы promise.then
.then(async (data) => {. Вы можете определить встроенные асинхронные обратные вызовы.
хорошо, спасибо, ребята!
@EmileBergeron Нет, не смешивайте async функции в .then(…) цепочку!
@ Берги, это вопрос предпочтений. Я никогда не использую aync/await как личное предпочтение. В вашем комментарии должно быть написано: Предпочтительно придерживаться одного или другого, но не смешивать оба стиля..
@EmileBergeron Да, именно это я и имел в виду: не смешивайте их.
@Bergi "Нет, не надо" звучит так, как будто это не сработает. Хотя это работает, я согласен, что это непоследовательно!
это была ссылка, так что там немного больше контекста :)
Мой комментарий остается в силе, вы можете определить встроенные асинхронные обратные вызовы, и это то, что нужно ОП. Стили «не смешивать» должны были быть адресованы OP, а не мне.
согласен, то, что вы написали, действительно. Как правило, это не очень хорошая практика, но она все еще действительна. Я думаю, что это было направлено как на ОП, так и на вас, в том смысле, что @Bergi говорил, что вы не должны рекомендовать что-то, что не является хорошей практикой. Например, я мог бы порекомендовать кому-то написать 3 цикла for, чтобы выполнить то, что сделал бы 1 цикл for, и технически это допустимо... но это не значит, что я должен его рекомендовать. Во всяком случае, это то, что я понял из этого комментария :)
Так мне продолжать пользоваться или нет?
Вы должны быть последовательны @Danks. Вероятно, лучше всего использовать асинхронное ожидание для всего.
Ok! @JohnRuddell, большое спасибо, чувак! и спасибо за ваш ответ о рефакторинге и примере кода!
@Дэнкс, да! Рад был помочь! :) когда вы начинаете копировать и вставлять что-то или переписывать что-то, обычно самое время остановиться и подумать о том, как вы это используете, и о вариантах использования, которые дают ритм для рефакторинга :) Удачного кодирования!
Ok! @JohnRuddell, спасибо за совет! Короче говоря, в любом обещании просто используйте оператор try catch! :)
ну попробуй поймать с асинхронным ожиданием. если вы использовали обещания, вы можете .then и .catch по сути делать то же самое
@JohnRuddell Я не рекомендовал смешивать оба стиля, просто случайно упомянул об отсутствующем встроенном async. Это может произойти за пределами цепочки обещаний, и OP может быть полезно знать, что это работает именно так. Кроме того, хорошо поделиться передовым опытом, как вы оба это сделали, но не вините меня за помощь!
Не обвиняя, не перекладывая вину или что-то в этом роде. Просто интерпретация комментария, сделанного другим, вокруг цели комментария. Следовательно, мой голос за ваш комментарий о встроенной асинхронности :) Я думаю, что с обеих сторон есть веские аргументы.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Вы должны реорганизовать то, как вы делаете свои запросы. У меня была бы общая функция для настройки запроса и всего остального.
const makeRequest = async (url, options, auth_token) => {
try {
// Default options and request method
if (!options) options = {}
options.method = options.method || 'GET'
// always pass a body through, handle the payload here
if (options.body && (options.method === 'POST' || options.method === 'PUT')) {
options.body = JSON.stringify(options.body)
} else if (options.body) {
url = appendQueryString(url, options.body)
delete options.body
}
// setup headers
if (!options.headers) options.headers = {}
const headers = new Headers()
for(const key of Object.keys(options.headers)) {
headers.append(key, (options.headers as any)[key])
}
if (auth_token) {
headers.append('Access', auth_token)
}
headers.append('Accept', 'application/json')
headers.append('Content-Type', 'application/json')
options.headers = headers
const response = await fetch(url, options as any)
const json = await response.json()
if (!response.ok) {
throw json
}
return json
} catch (e) {
console.error(e)
throw e
}
}
appendQueryString — небольшая вспомогательная утилита для получения параметров qs в URL-адресе.
const appendQueryString = (urlPath, params) => {
const searchParams = new URLSearchParams()
for (const key of Object.keys(params)) {
searchParams.append(key, params[key])
}
return `${urlPath}?${searchParams.toString()}`
}
Теперь, чтобы перейти к тому, как вы обновляете свой код, вы заметите, что все становится менее подробным и более обширным.
async infiniteNotification(page = 1) {
try {
let auth_token = await AsyncStorage.getItem(AUTH_TOKEN);
const data = await makeRequest(
`/notifications`,
{ body: { page } },
auth_token
)
var allData = this.state.notifications.concat(data.notifications);
this.setState({
notifications: allData,
page: this.state.page + 1,
});
const markedAsReadResponse = makeRequest(
"/notifications/mark_as_read",
{
method: "POST",
body: {
notification: { read: true }
},
auth_token
)
this.props.changeNotifications();
} catch (e) {
// TODO handle your errors
}
}
/notifications?page=${page} это не удастся, поскольку вы добавляете строку запроса на основе тела?
Да, или хорошо, это был бы просто второй параметр qs. Может не выйти из строя, но все равно не должно быть там. Я обновлю это. Хорошо поймал :)
ваши внутренние функции не асинхронны. я бы не стал использовать
.then