React: Sob quais circunstâncias, unstable_shouldYield retornará verdadeiro？

Criado em 8 fev. 2019 · 4Comentários · Fonte: facebook/react

Em Scheduler.js,

function unstable_shouldYield() {
  return (
    !currentDidTimeout &&
    ((firstCallbackNode !== null &&
      firstCallbackNode.expirationTime < currentExpirationTime) ||
      shouldYieldToHost())
  );
}

unstable_shouldYield () retorna verdadeiro quando currentDidTimeout é falso e deveYieldToHost () retornar verdadeiro, mas por quê?

shouldYieldToHost = function() {
  return frameDeadline <= getCurrentTime();
};

shouldYieldToHost () retornar verdadeiro significa que não há tempo restante neste período de inatividade
currentDidTimeout é falso significa que a programação não atingiu o tempo limite
que relação entre eles, por que unstable_shouldYield () depende deles?

Question

Fonte

xilixjd

Comentários muito úteis

Nós cedemos ao ambiente do host periodicamente - a cada 16 ms ou mais - para permitir a navegação para processar os eventos de entrada, incluindo a entrada do usuário. frameDeadline é o carimbo de data / hora que planejamos produzir (originalmente definido como now() + 16ms ), portanto, shouldYieldToHost retorna verdadeiro quando esse tempo passa. Em seguida, usamos alguma combinação de requestIdleCallback e requestAnimationFrame para que possamos processar o próximo trabalho em breve.

No caso ideal, podemos terminar toda a renderização nessas pequenas fatias de 16ms. No entanto, se houver muitas outras coisas acontecendo ao mesmo tempo, o trabalho do React pode "morrer de fome" e não ser capaz de renderizar totalmente nas pequenas fatias. Portanto, temos uma segunda verificação: cada renderização pendente ou atualização de estado tem um "tempo de expiração" (geralmente em algum lugar de 100ms a 5000ms) - se esse tempo passar sem a finalização da renderização, mudamos para o modo síncrono até que a atualização possa ser concluída. Isso não é o ideal, mas garante que todas as atualizações sejam processadas sem esperar muito.

Definimos um cronômetro no navegador (por exemplo, com setTimeout) para o mesmo tempo de expiração. Se esse cronômetro disparar, sabemos que precisamos realizar o trabalho de forma síncrona. Se isso acontecer, currentDidTimeout é definido como verdadeiro, portanto, não renderemos.

No futuro, planejamos usar uma nova API do navegador isInputPending (https://github.com/WICG/is-input-pending) para que possamos continuar processando o trabalho e só produzir resultados quando houver uma nova entrada do usuário , em vez de sempre render a cada 16 ms.

sophiebits em 9 fev. 2019

👍6

Todos 4 comentários

sophiebits em 9 fev. 2019

👍6

Obrigado pela resposta
Eu ainda tenho algumas perguntas,

Acho que unstable_shouldYield() representa se o trabalho pode ser interrompido ou não na programação, correto?
Os "16 ms" referem-se a activeFrameTime ?
Quando firstCallbackNode.expirationTime < currentExpirationTime retornará verdadeiro? Isso significa que a prioridade do próximo trabalho é maior do que o anterior?

xilixjd em 10 fev. 2019

Cada tarefa de renderização deve verificar unstable_shouldYield () freqüentemente. (Chamamos isso mais ou menos depois de cada componente na árvore.) Na maioria das vezes, ele retornará falso (o que significa continuar), mas quando retornar verdadeiro, isso significa que a renderização precisa pausar.
sim.
Acredito que essa condição seja verdadeira se algum trabalho mais recente e de maior prioridade for enfileirado durante uma renderização existente. Nesse caso, queremos retornar true para que possamos alternar para essa tarefa.

sophiebits em 10 fev. 2019

👍2

Muito obrigado. É muito legal da sua parte!

xilixjd em 10 fev. 2019

Esta página foi útil?

0 / 5 - 0 avaliações