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

Använd alltid AbortController

TA ALLTID BORT HÄNDELSEHANTERARE I disconnectedCallback. ENKELT MED AbortController. NU FINNS DET INGA URSÄKTER LÄNGRE! Läs artikeln Event Listener Management in Web Components och framför allt det som står under rubriken “Using AbortController”.

📕 Errata

Använd alltid gemener i händelsenamn

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å:

   this.dispatchEvent(new window.CustomEvent('timeisup'))

och INTE

  this.dispatchEvent(new window.CustomEvent('timeIsUp'))

Historiskt resonemang, se nedan

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.

• Inledning
• Webbkomponentens livscykel
• connectedCallback
• disconnectedCallback
• Utlösa egna händelser (synthetic events)