JavaScript

En ting vi liker å diskutere på frontend-utvikling er hvordan tilstand (state) skal behandles. Skal man ha all tilstand lagret globalt på et slags toppnivå? Skal man transformere noe før det sendes til UI-komponentene? Når er det greit med lokal tilstand i en komponent? I denne posten forklares et slags mønster som jeg synes fungerer veldig bra for søkesider.

Web-analyse for 100% av brukerne uten begredelige samtykke-dialoger er mulig — her er hvordan.

Alle moderne nettlesere har nå en innebygget byggekloss som hjelper oss å lage gode dialoger og modaler. Hvis du, som meg, slettes ikke var klar over det, så er dette innlegget for deg.

For mange norske datasystemer virker det som helligdager og høytidsdager kommer som en overraskelse. Hvor vanskelig kan det egentlig være å lage et system som ikke setter betalingsfrist på en dag hvor bankene er stengt? Eller venter med å sende purring på tilbakelevering av ting til en dag man faktisk har åpent? Vi dykker ned i matte fra 1800-tallet og lurer på hvorfor dette ikke er implementert i alle norske datasystem…

En forutsetning for å treffe med softwaredesign er at vi har god kontroll på domenet vi opererer i. Men hva er egentlig domenet til frontendkoden din?

Mesteparten av whitespace i HTML er irrelevant og fjernes av browseren. Så lenge vi lager HTML-koden selv fungerer dette flott. Men hva skjer om man for eksempel lager en editor som skal støtte HTML både inn og ut - og noen limer inn HTML-kode med forskjellig typer spaces?

Det er lite vi utviklere elsker mer enn å peke på galskap i JavaScript, så som [] + 2 === "2", men dersom jobben din er å skrive kode i dette språket, eller språk som kompilerer til JavaScript uten å skjule denne oppførselen (eksempelvis TypeScript og ClojureScript) vil du spare mye tid i feilsøking og koding ved å forstå hvorfor ting er som de er.

Hvordan funker et Set i JavaScript og når passer det å bruke det?