Share
"Intersection Observer" gir en måte å asynkront observere endringer i krysset (overlappende) av elementer. Dette kan være i forhold til andre elementer, eller visningsporten. I denne artikkelen tar vi en titt på noen demoer og diskuterer relevansen som Intersection Observer vil spille i fremtiden for webutviklere. Jeg vil også dele kodeeksempler for å hjelpe deg med å komme i gang for de sene natteksperimentene. La oss dykke inn!
De IntersectionObserver API lar deg registrere en tilbakeringingsfunksjon som utføres når et element som blir overvåket, går inn eller ut av et annet element, eller visningsporten.
Det er mange ideer og forslag delt i denne W3C explainer doc på GitHub, men Intersection Observer kan være nyttig for å bygge opp funksjoner som:
Sjekk ut denne demoen av Dan Callahan for å avklare hva vi snakker om:
Å komme i gang med IntersectionObserver la oss utforske de nødvendige kodingstrinnene som kreves. Du kan alltid sørge for at de tiltenkte nettleserne / enhetene dine støtter IO API ved å referere til caniuse. Vi begynner med å lage en observatør og diskutere hvordan det kan brukes til å overvåke komponenter.
IntersectionObserver starter ved å kreve en gruppe valgmuligheter definert som et objekt bokstavelig og bestått som et argument til det definerte observasjonsobjektet.
la alternativer = root: null, // i forhold til dokumentevisningsport rootMargin: '0px', // margin rundt rot. Verdiene ligner css eiendom. Unitless verdier ikke tillatt terskel: 1.0 // synlig mengde element vist i forhold til root; la observatør = ny IntersectionObserver (tilbakeringing, alternativer);
Disse observatøralternativene i linjene 2-4 vil diktere noen viktige detaljer når det gjelder å oppdage synligheten til et målelement i forhold til roten. Det første argumentet til observatørobjektet (siste linje) representerer en tilbakeringing (funksjon) som utføres etter hvert som krav oppfylles av observatøren. Det andre argumentet refererer til vårt objekt som inneholder observatørens alternativer og aksepterer følgende egenskaper:
Accentsconagua
rot: Elementet du vil teste krysset mot. En verdi på null refererer til nettleserens visningsport. Du kan også passere DOM-seleksjonsmetoder som document.querySelector ( '# mytargetobject').rootMargin: Hvis du trenger å utvide eller krympe den effektive størrelsen på rotelementet før du beregner kryss. Disse verdiene som passerer, er lik CSS margin eiendom. Hvis rot Elementet er angitt, verdiene kan være prosenter.terskel: Enten et enkelt nummer eller en rekke tall som angir hvilken prosentandel av målets synlighet utløser observatørens tilbakeringing. En verdi på 1,0 betyr at terskelen ikke vurderes passert før hver piksel er synlig, mens 0 betyr at elementet ikke er helt synlig.Som jeg tidligere nevnte, håndterer du tilbakekallingsargumentet ved å opprette en funksjon som inneholder tilpasset logikk basert på prosjektets behov. Denne logikken utføres når et observert element (e) er synlig i forhold til det definerte rotelementet.
funksjonen på Endre (endringer, observatør) // logikk går her la observatør = ny IntersectionObserver (onChange, alternativer);
Logikk innenfor observatørens funksjon kan være hendelser som lasting av bilder, legge til / fjerne klasser eller kontrollere synlighet, men valget er ditt om hva som kan gjøres innvendig avhengig av dine behov og mål.
Hver gang observatøren oppdager en endring, a Endringer Hendelsen er rapportert (slags som a funksjon() rapporterer et hendelsesobjekt) fra observatøroppringningen. Ved å bruke denne utløste hendelsen, kan vi sjekke for synlighet av elementet vårt i forhold til roten før du kjører ytterligere logikk ved å oppdage egenskaper på endring begivenhet. Noen utviklere vil erstatte Endringer med ordet innganger i stedet, men begge tilnærminger fungerer det samme.
funksjonen endre (endringer, observatør) changes.forEach (change => if (change.intersectionRatio> 0) // din observatørlogikk);
Denne sløyfen sier "For hver endring oppdaget, sjekk for å se om målelementet for øyeblikket er synlig (større enn 0) i forhold til den definerte roten." Skjæringsforholdet hjelper til med å rapportere hvor mye av elementet som er synlig ved hjelp av en verdi mellom 0,0 (ikke synlig) og 1,0 (fullt synlig). Du kan tenke på skjæringsforholdet akkurat som terskel eiendom definert i observatørens valg.
Så langt har vi opprettet et alternativobjekt, en tilbakeringingsfunksjon og definert et observatørobjekt, men vi har fortsatt ikke noe å observere. Det er her observatormetoden kommer i bruk.
la bilder = document.querySelectorAll ('img'); images.forEach (img => observer.observe (img));Denne metoden legger til et element i settet med målelementer som overvåkes av IntersectionObserver. I dette eksemplet observerer jeg hvert bilde på siden av resultatene hentet fra Bilder velgereferanse. De observere() Metoden vil fortsette å overvåke et mål til et av følgende skjer: unobserve () eller koble fra() metoder kalles sammen med målelementet eller skjæringsroten slettet. Hvis du ikke lenger trenger å observere et element, er det best å ringe til unobserve () og passere i målet ditt som argumentet.
Hvis du trenger å teste støtten til denne API-en, kan du pakke alt i en hvis/ellers betinget utsagn som slik:
hvis ('IntersectionObserver' i vinduet) // støttet annet // ikke støttetSiden API-modulen for gjennomsøkingsobservatoriet fortsatt ligger på et arbeidsutkaststadium, oppfordrer jeg deg til å registrere deg vindu objekt, eller du kan også finne polyfills hvis du foretrekker det.
Følgende demo inneholder all koden jeg har diskutert så langt med noen ekstra tweaks. Denne demoen er lat laster bilder når de viser 50% av synligheten i forhold til visningsporten.
Du kan merke en forskjellig oppførsel når det gjelder bilde elementer i forhold til img elementer i Chrome og Firefox. Begge nettleserne laster bilde elementer perfekt, men bilde se bort fra terskelen vår selv med definerte absolutt størrelse begrensninger. De ser ut til å laste når de er omtrent 10% i visning vs. 50% terskelen som er definert i demoen. Legg igjen en kommentar nedenfor hvis du merker dette underlig, eller har opplevd problemer med IntersectionObserver og bilde nærmere bestemt.
Her er en annen demo som lager et uendelig rullescenario som lat laster bilder med Ajax for å laste bilder etter behov.
I dette scenariet legger jeg inn en melding til DOM som mitt observerte mål. Denne sentinel er plassert ved siden av det siste elementet i den uendelige scroller, og som sentinel kommer til syne, laster tilbakeringingen dataene, skaper neste element (er), fester dem til DOM og reposisjonerer sentinelet. Hvis du resirkulerer sentinelet riktig, er det ingen ekstra anrop til observere() Er pålagt. Her er et flott diagram av Google Developer-teamet for å bidra til å visuelt forklare denne tilnærmingen.
Når en img element med en begrensning av maksimal bredde: 100% blir observert, vil det ikke lykkes å laste. Det betyr at alle bilder som er lastet på lat måte må ha begrensninger definert i CSS eller inline i samsvar med Problemet med bilde elementer som mangler noen begrensninger er at det er null størrelse før innholdet er lastet; som betyr at de alle krysser visningsporten samtidig som du ruller. Jeg mistenker getBoundingClientRect () er en del av grunnen da dette er en av de primære metodene for å oppnå et elements koordinater og begrensninger.
Bruker du IntersectionObserver i ditt eget arbeid rett i minuttet? Er du glade for denne funksjonen og mulighetene det bringer? kunne IntersectionObserver erstatt behovet for hendelsesbaserte funksjoner som stilling: klebrig? Personlig føler jeg at denne nye API er et solidt tillegg til våre spesifikasjoner, og jeg ser ivrig fram til fortsatt vekst i de kommende årene.
Jeg har tatt med noen nyttige lenker nedenfor og oppfordrer deg til å dykke dypere på fritiden din. Hver lenke vil hjelpe deg med å få en bedre forståelse av hvordan denne nye API fungerer og fungerer. Hvis du har noen tips eller triks for andre lesere, legg dem i kommentarene nedenfor. Som alltid, lykkelig koding!
