Observação de interseções Observadores

À medida que o desenvolvimento para a Web amadureceu e os mecanismos JavaScript se tornaram mais rápidos, uma área continua sendo um gargalo significativo: a renderização. É por isso que muitos dos esforços de desenvolvimento recentes têm se concentrado na renderização, sendo o DOM virtual um dos exemplos mais populares. Em Dojo 2, estar ciente dessas novas APIs e abordagens tem sido uma prioridade. Mas trabalhar com uma nova API tem seus desafios e o API do observador de interseção não é diferente;

Os observadores de interseção têm o objetivo de fornecer “uma maneira de observar de forma assíncrona as alterações na interseção de um elemento de destino com um elemento ancestral ou com a janela de visualização de um documento de nível superior”. Isso permitirá que os sites carreguem imagens e outras mídias de forma preguiçosa, renderizem e removam o DOM sob demanda, como seria necessário para uma grade de milhões de linhas, e forneçam rolagem infinita, como podemos ver em um feed de rede social;

Mas os Intersection Observers também resolvem um problema maior, que não é imediatamente óbvio para nós, desenvolvedores, e que foi descrito no relatório do Web Incubator Community Group Explicação do Intersection Observer documento: exibição de anúncios. O Interactive Advertising Bureau tem uma política de que os anúncios devem estar 50% visíveis por mais de um segundo contínuo. Como a publicidade de terceiros e os scripts de impressão de página são notórios por contribuírem para o inchaço da página, essa API parece ainda mais importante;

Todos nós deveríamos começar a trabalhar imediatamente na integração dos Intersection Observers em nossos projetos? Infelizmente, há uma série de desafios, inconsistências e bugs que, no momento, fazem com que isso esteja fora do alcance e da liderança do implementação de polyfill tem uma série de problemas pendentes. Mas isso não significa que a capacidade de usar os Intersection Observers esteja distante e esperamos que, ao delinear os problemas, criar testes e enviar relatórios de bugs, o uso viável esteja a apenas alguns meses de distância;

Como funciona

Os observadores de interseção funcionam em duas partes: uma instância de observador anexada a um nó específico ou à viewport geral e uma solicitação a esse observador para monitorar filhos específicos dentro de seus descendentes. Quando o observador é criado, ele também é fornecido com um retorno de chamada que recebe uma ou mais entradas de interseção;

const observer = new IntersectionObserver((entries) = > { 
    entries.forEach(entry = > console.log(entry.target, entry. intersectionRatio));
  }); 
  observer.observe(node);

Essas entradas são o coração da API. Cada uma delas tem informações que descrevem a alteração da interseção e o nó cuja visibilidade está sendo alterada no momento. Três propriedades estão no centro desses objetos de entrada, cada uma fornecendo uma dimensão de informações diferentes:

• 
  isIntersecting indica se o nó atribuído ao target é visível na raiz do observador
• 
  intersectionRatio é um número entre 0 e 1 que indica a proporção da visão do alvo dentro da raiz do observador
• 
  intersectionRect é um objeto com números que indicam o tamanho, com largura e altura, e a posição, com cima, esquerda, baixo e direita

Embora a API seja simples, seu uso pode ser complexo e exclusivo para cada caso de uso. Vários exemplos são fornecidos na seção Explicação do Intersection Observer documento.

Problema: uma proporção de 0

Um dos bugs mais fáceis de encontrar é uma taxa de interseção de 0. É um problema porque pode acontecer tanto
quando um nó está se tornando visível e quando um nó não está mais visível. No exemplo abaixo, ao percorrer as
linhas, o senhor pode notar que uma proporção de 0 aparece ocasionalmente. Caso contrário, role a tela bem devagar até que a próxima linha apareça;

Este exemplo está lendo o intersectionRatio da propriedade IntersectionObserverEntry passada para o retorno de chamada. Parece uma propriedade lógica a ser usada para detectar uma interseção – afinal, uma taxa de interseção de 0 não significaria que ela não é visível? Mas se tivermos um código que seja executado somente se essa proporção for diferente de zero, ele nunca será executado. Além disso, se apenas um único nó estiver sendo observado e a taxa de interseção de 0 for ignorada, nenhum outro evento será disparado e nenhuma atualização de conteúdo será realizada;

A solução para isso é usar o isIntersecting que só é verdadeira se esse nó estiver visível ou se estiver se tornando visível. Infelizmente, se esse código estivesse sendo escrito em TypeScript, essa propriedade, no momento em que este texto foi escrito, seria verdadeira, não existia na interface IntersectionObserverEntry, portanto, seria fácil não perceber.

Cuidado: Criança gigante

Ao criar um novo Intersection Observer, várias opções de configuração podem ser passadas, incluindo vários limites que permitem que uma entrada de interseção e um evento associado sejam disparados à medida que a porcentagem de sua visibilidade muda;

No Especificação do W3C, uma entrada de interseção é criada quando “intersectionRatio é maior do que a última entrada em observer.thresholds“, onde essa proporção é “intersectionArea dividido por targetArea.” Quando um nó é maior do que o nó raiz que o observa, essa proporção aumentará constantemente até que o nó filho o preencha, momento em que o valor nunca chegará a 1, mas permanecerá a proporção geral de suas duas alturas;

Isso pode ser confuso se estivermos esperando intersectionRatio aumente constantemente entre 0 e 1, o que não é um objetivo da API Intersection Observer e não tem uma maneira lógica de ser calculado. Mas mesmo que esse comportamento seja bem compreendido, deve-se observar que os eventos param de ser disparados quando essa proporção não muda mais. Mesmo que intersectionRect.top continue a mudar e possa ser útil para o nosso retorno de chamada, a proporção em si não está mudando. 13;

Em esta demonstraçãoNa demonstração, os logs do console mostram entradas de interseção para 3 nós – acima, gigante e abaixo – com um grande número de limites indicando cada alteração de 1% na taxa de interseção. Preste atenção em quando o “gigante” preenche a exibição principal e para de emitir eventos. 13;

Caution: Eventos duplicados ou ausentes

À medida que a especificação se torna mais clara e os casos extremos são documentados, haverá diferenças entre os navegadores e o polyfill que devem ser esperadas e gerenciadas. Lendo a discussão em esta questão ilustra algumas das áreas da especificação que ainda precisam ser trabalhadas, algumas áreas em que a especificação foi alterada devido a essa discussão e até mesmo explicações dos desenvolvedores de navegadores sobre por que as decisões foram tomadas da maneira que foram. 13;

Em este exemplo, podemos abrir o console para monitorar os eventos. No momento em que este artigo foi escrito, podíamos ver o Firefox ocasionalmente emitindo duas entradas quando um nó se tornava visível. Embora seja mais um caso extremo, no problema vinculado acima, também há situações em que um evento pode não ser emitido. Até que essas situações sejam corrigidas, certifique-se de que sua implementação não será interrompida, especialmente com eventos duplicados… -#13;

Problema: Polyfill

No momento em que este artigo foi escrito, o polyfill Intersection Observer substitui incorretamente as implementações nativas de IntersectionObserver devido a uma referência não global. As versões anteriores não conseguiram aplicar o polyfill quando a implementação nativa estava incorreta, o que significa que uma versão corrigida deve ser usada até que haja uma nova versão. 13;

Atualmente, o polyfill é acionado somente na rolagem do documento, no redimensionamento da janela e na mutação do DOM com um cálculo de interseção acelerado/descontinuado após 100 ms. Foi aberto um problema para o adicionar eventos de animação e transição para abranger mais tipos de eventos. A especificação do W3C observa que a detecção de interseção nativa “[requires] exige um esforço extraordinário do desenvolvedor, apesar de seu uso generalizado” e, portanto, é de se esperar que seja difícil obter 100% de cobertura. 13;

Por fim, há uma situação em que o polyfill não informará uma interseção. Como ele é totalmente orientado por eventos, chamar o .observe em um nó já existente no DOM não calcula as interseções. Temos enviamos um problema que recria essa situação. 13;

Cuidado: scrollTop

Embora esse aviso não esteja diretamente relacionado aos observadores de interseção, é provável que cause problemas ao usar um elemento inline com rolagem. Os navegadores escolheram abordagens diferentes para o que acontece quando os nós sofrem mutação em um elemento inline de rolagem;

No Chrome, adicionar e remover nós ajustará automaticamente a posição de rolagem do pai, por meio da função scrollTop propriedade. Outros navegadores, como o Safari, por exemplo, não realizam esse cálculo. Por esse motivo, o senhor precisará contornar essa limitação ajustando manualmente a propriedade scrollTop com base nas alterações de tamanho dos nós que aparecem antes da primeira linha visível. 13;

Prognóstico: Getting There

Se for possível presumir que todos os usuários que visitam um aplicativo Web avançado estarão usando a versão mais recente dos principais navegadores, há desenvolvimento ativo e eliminação de bugs suficientes para presumir que teremos uma API estável em um futuro próximo;

Mas, como a maioria dos projetos não pode fazer essa suposição, o polyfill terá que se posicionar quando necessário. Embora também esperemos que esse código melhore, há limitações inerentes ao que pode ser calculado sem ter acesso ao pipeline de renderização e ao loop de eventos nativo. Usar CSS simples e saber que os eventos suportados correspondem ao seu caso de uso deve resultar em eventos de interseção utilizáveis;

Saiba mais

A SitePen oferece desenvolvimento e consultoria de aplicativos da Web para equipes empresariais em todo o mundo. Conecte-se com a SitePen hoje mesmo para expandir a experiência, o conhecimento e a capacidade da sua equipe de fazer mais… -#13;