Läs artikeln Event Listener Management in Web Components och framför allt det som står under rubriken "Using AbortController".
Inspelningar
Samtidighetsmodellen och eventdriven programmering
1h 43m | Presentation
- Introduktion
- Samtidighetsmodellen
- Stack och heap
- Händelsekön (The Task Queue)
- Timers och Interval
- Händelsestyrd programmering
- Webbläsarens inbyggda händelser (Event)
- Antipattern: onclick=""
- Lyssna på händelser (addEventListener)
- Exempel, vi fryster webbläsaren
- Ta bort händelsehanterare (removeEventListener)
- Händelser som utlöses en gång (option: once)
- Vad utlöste händelsen? (this, event.target)
- Closures
- Delegat (Event delegation)
- Stoppa det förvalda beteendet. (event.preventDefault)
- Propagation (capture, bubble)
- Web Worker API
- Avslutning
Webbkomponenter - Händelser
30m | Presentation
TA ALLTID BORT HÄNDELSEHANTERARE I disconnectedCallback. ENKELT MED AbortController. NU FINNS DET INGA URSÄKTER LÄNGRE!
📕 Errata
När vi arbetar med namn på händelser som vi skapar själva (custom events) så ska vi alltid sträva efter att namnge händelserna med gemener.
Gör alltså:
och INTE
En fråga som ofta förekommer är, var ska vi koppla våra händelsehanterare? I connectedCallback eller i konstruktorn. Som vanligt är beskedet. Det beror på.Händelsehanterare som sätts på element som är i vår shadowDOM sätter vi lämpligast i konstruktorn. Sätter vi händelsehanterare på något som är utanför vår shadowDOM så bör vi sätta dessa i connectedCallback vilket också innebär att vi i dessa fall behöver ta bort händelsehanterarna i disconnectedCallback.En bra genomgång kring detta [ges som svar på följande fråga på Stack Overflow.](https://stackoverflow.com/questions/59970043/custom-element-setup-constructor-vs-connectedcallback)
