Verificamos de forma profundamente cada sección de nuestra web con el objetivo de mostrarte en todo momento información veraz y actualizada.
Solución:
NO, no puedes obtener los datos sincrónicamente de una promesa como sugieres en tu ejemplo. Los datos deben usarse dentro de una función de devolución de llamada. Alternativamente, en el estilo de programación funcional, los datos de la promesa podrían mapearse.
Si está bien usar async/await (debería ser increíble), entonces puede escribir un código que parezca sincrónico pero que conserve la asincronía de una promesa (vea los comentarios de @loganfsmyth).
const foo, bar = await iAmAPromise.then(result => result.data);
En general, dado que ya está utilizando ES6, supongo que también está utilizando un transpilador. En cuyo caso definitivamente deberías dar asíncrono/espera un intento. Solo asegúrese de tener en cuenta la decisión de que, a día de hoy, aún no son una especificación ratificada.
Si bien puede obtener un valor de una Promesa esperada dentro de una función asíncrona (simplemente porque detiene la función para esperar un resultado), nunca puede obtener un valor directamente de una Promesa y volver al mismo alcance que la Promesa misma. .
Eso es porque “fuera de” significaría tratar de tomar algo que existe en el futuro (el valor finalmente resuelto) y ponerlo en un contexto (asignación de variable síncrona) que ya pasó en el pasado.
Es decir, viajes en el tiempo. E incluso si el viaje en el tiempo fuera posible, probablemente no sería una buena práctica de codificación porque el viaje en el tiempo puede ser muy confuso. 🙂
En general, si siente que necesita hacer esto, es una buena señal de que necesita refactorizar algo. Tenga en cuenta que lo que está haciendo con “resultado => resultado.datos” aquí:
Promise.then(result => result.data, errorHandler);
// rest of script
..es ya un caso de usted trabajando con (literalmente, mapeando) el valor pasándolo a una función. Pero, suponiendo que “// el resto del script” haga algo importante relacionado con este valor, probablemente desee Seguir mapeando el valor ahora actualizado con otra función que luego hace algo secundario con el valor (como mostrar los datos en la pantalla).
Promise
.then(result => result.data)
.then(data => doSomethingWithData)// rest of script
.catch(errorHandler);
“doSomethingWithData” se llamará (si alguna vez se llama) en algún punto desconocido en el futuro. Por eso es una buena práctica encapsular claramente todo ese comportamiento en una función específica y luego conectar esa función a la cadena Promise.
Honestamente, es mejor de esta manera, porque requiere que declares claramente una secuencia particular de eventos que voluntad suceda, separado explícitamente de la primera ejecución a través de toda la ejecución del código de su aplicación.
Para decirlo de otra manera, imagine este escenario, ejecutado hipotéticamente en el alcance global de nivel superior:
const foo, bar = Promise.then(result => result.data, errorHandler);
console.log(foo);
//...more program
¿Qué esperarías que sucediera allí? Hay dos posibilidades, y ambas son malas.
- Todo su programa sería tener detenerse y esperar a que se ejecute la Promesa antes de que pudiera saber qué harían “foo” y “bar”… no, puede que ser. (esto es lo que “esperar”, dentro de una función asíncrona, de hecho hace: pausa toda la ejecución de la función hasta que el valor esté disponible o se produzca un error)
- foo y bar simplemente no estarían definidos (esto es lo que realmente sucede), ya que, al ejecutarse sincrónicamente, serían propiedades inexistentes del objeto Promise de nivel superior (que no es en sí mismo un “valor”, sino más bien un envoltura cuasi-monádica alrededor consiguiendo un valor eventual O un error) que muy probablemente no incluso contener un valor todavía.
Recuerda que puedes difundir esta división si te ayudó.