React: ¿Bajo qué circunstancias, unstable_shouldYield devolverá verdadero?
En Scheduler.js,
function unstable_shouldYield() {
return (
!currentDidTimeout &&
((firstCallbackNode !== null &&
firstCallbackNode.expirationTime < currentExpirationTime) ||
shouldYieldToHost())
);
}
unstable_shouldYield () devuelve verdadero cuando currentDidTimeout es falso y shouldYieldToHost () devuelve verdadero, pero ¿por qué?
shouldYieldToHost = function() {
return frameDeadline <= getCurrentTime();
};
shouldYieldToHost () return true significa que no queda tiempo en este período de inactividad
currentDidTimeout es falso significa que el horario no es el tiempo de espera
¿Qué relación entre ellos, por qué unstable_shouldYield () depende de ellos?
xilixjd
Todos 4 comentarios
Cedemos el paso al entorno del host periódicamente, cada 16 ms aproximadamente, para permitir que el navegador procese los eventos entrantes, incluida la entrada del usuario. frameDeadline es la marca de tiempo en la que planeamos ceder (originalmente establecida en algo como now() + 16ms ), por lo que shouldYieldToHost devuelve verdadero una vez que haya pasado ese tiempo. Luego usamos una combinación de requestIdleCallback y requestAnimationFrame para que podamos procesar el siguiente trabajo pronto.
En el caso ideal, podemos terminar todo el renderizado en estos pequeños cortes de 16 ms. Sin embargo, si hay muchas otras cosas sucediendo al mismo tiempo, el trabajo de React puede "morir de hambre" y no ser capaz de renderizar por completo en las pequeñas porciones. Así que tenemos una segunda verificación: cada renderizado o actualización de estado pendiente tiene un "tiempo de caducidad" (generalmente entre 100ms y 5000ms); si ese tiempo pasa sin que el renderizado termine, cambiamos a un modo síncrono hasta que esa actualización pueda finalizar. Esto no es ideal, pero garantiza que todas las actualizaciones se procesen sin esperar demasiado.
Configuramos un temporizador en el navegador (por ejemplo, con setTimeout) para ese mismo tiempo de vencimiento. Si ese temporizador se activa, sabemos que debemos realizar el trabajo de forma sincrónica. Si esto sucede, currentDidTimeout se establece en verdadero, por lo que no cederemos.
En el futuro, planeamos usar una nueva API de navegador isInputPending (https://github.com/WICG/is-input-pending) para que podamos continuar procesando el trabajo y solo ceder cuando haya una nueva entrada de usuario , en lugar de ceder siempre cada 16 ms.
sophiebits
en 9 feb. 2019
Gracias por responder
Todavía tengo algunas preguntas,
- Creo que
unstable_shouldYield()representan si el trabajo se puede interrumpir o no en el horario, ¿es correcto? - ¿El "16ms" se refiere a
activeFrameTime? - ¿Cuándo se volverá verdadero
firstCallbackNode.expirationTime < currentExpirationTime? ¿Significa eso que la prioridad del próximo trabajo es mayor que la del anterior?
xilixjd
en 10 feb. 2019
Cada tarea de renderizado debe comprobar unstable_shouldYield () con frecuencia. (Lo llamamos aproximadamente después de cada componente en el árbol). La mayoría de las veces devolverá falso (lo que significa continuar), pero cuando devuelve verdadero, significa que la representación debe detenerse.
Si.
Creo que esa condición es verdadera si algún trabajo más nuevo y de mayor prioridad se pone en cola durante un render existente. En ese caso, queremos devolver verdadero para poder cambiar a esa tarea.
sophiebits
en 10 feb. 2019
Muchas gracias, es muy amable de tu parte.
xilixjd
en 10 feb. 2019
Temas relacionados
Prinzhorn
·
3Comentarios
framerate
·
3Comentarios
kocokolo
·
3Comentarios
krave1986
·
3Comentarios
jimfb
·
3Comentarios
Comentario más útil
Cedemos el paso al entorno del host periódicamente, cada 16 ms aproximadamente, para permitir que el navegador procese los eventos entrantes, incluida la entrada del usuario.
frameDeadlinees la marca de tiempo en la que planeamos ceder (originalmente establecida en algo comonow() + 16ms), por lo que shouldYieldToHost devuelve verdadero una vez que haya pasado ese tiempo. Luego usamos una combinación de requestIdleCallback y requestAnimationFrame para que podamos procesar el siguiente trabajo pronto.En el caso ideal, podemos terminar todo el renderizado en estos pequeños cortes de 16 ms. Sin embargo, si hay muchas otras cosas sucediendo al mismo tiempo, el trabajo de React puede "morir de hambre" y no ser capaz de renderizar por completo en las pequeñas porciones. Así que tenemos una segunda verificación: cada renderizado o actualización de estado pendiente tiene un "tiempo de caducidad" (generalmente entre 100ms y 5000ms); si ese tiempo pasa sin que el renderizado termine, cambiamos a un modo síncrono hasta que esa actualización pueda finalizar. Esto no es ideal, pero garantiza que todas las actualizaciones se procesen sin esperar demasiado.
Configuramos un temporizador en el navegador (por ejemplo, con setTimeout) para ese mismo tiempo de vencimiento. Si ese temporizador se activa, sabemos que debemos realizar el trabajo de forma sincrónica. Si esto sucede,
currentDidTimeoutse establece en verdadero, por lo que no cederemos.En el futuro, planeamos usar una nueva API de navegador
isInputPending(https://github.com/WICG/is-input-pending) para que podamos continuar procesando el trabajo y solo ceder cuando haya una nueva entrada de usuario , en lugar de ceder siempre cada 16 ms.