Dette var uka for å være på den sikre siden, hjelpsomme readmes og uventet suksess — og 224 andre ting som skjedde i frontend-verdenen!
Ikke vær redd for å overkomplisere
For to år siden skapte CSS-guruen Kevin Powell oppstyr med en video der han kondenserte fire kodelinjer til to. Han ble kritisert for å overkomplisere enkel, leselig kode og spre dårlige praksiser.
På årets CSS Day-konferanse tok han opp temaet igjen, og opptaket ble postet forrige uke.
Rabalderet startet med denne kodesnutten, som sentrerer et element med en maksimal bredde på 600px og gir det litt padding:
.wrapper {
width: 100%;
max-width: 600px;
padding: 0 1em;
margin: 0 auto;
}
Dette minimerte Powell til to linjer med bruk av den da nye min-funksjonen:
.wrapper {
width: min(100% - 2rem, 600px);
margin-inline: auto;
}
Hvilken syns du er enklest å forstå?
Etter å ha blitt kalt en “CSS noob” for å ha gjort enkel kode mer komplisert, vurderte han å fjerne videoen. Likevel valgte han å beholde den, siden den åpner for en viktig diskusjon: Hvor går grensen mellom overkomplisering og det som bare er uvant?
Nye funksjoner kan virke uvante, og noen ganger trenger du mer avansert kode. Likevel kan du gjøre tiltak for å gjøre koden mer forståelig for andre.
Et nyttig triks i CSS er å bruke CSS-variabler for å tydeliggjøre hvordan koden kan endres. Her er et lengre eksempel som viser nytten:
.columns {
/* user setting */
--min-column-size: 200px;
--column-count: 4;
--gap: 2rem;
/* calculations */
--breakpoint: calc(var(--min-column-size) * var(--column-count) + (var(--gap) * (var(--column-count) - 1)) );
--column-size: calc((100% / var(--column-count)) - var(--gap));
display: grid;
gap: var(--gap);
grid-template-columns: repeat(
auto-fit,
minmax(
min(max(var(--column-size), (100% - var(--breakpoint)) * -999 ), 100%),
1fr)
);
}
Å tilby utviklere enkle måter å endre noe på er også mulig i andre teknologier, som å eksponere relevante parametere i en funksjon eller navngi mystiske verdier.
Så hvor går grensen mellom “god overkomplisering” og “[sett-inn-gitt-teknologi] noob”? Kevin Powell argumenterer for at du skal tillate deg selv å overkomplisere for å eksperimentere med nye måter å gjøre ting på, men stadig ha et øye til lesbarhet.
Om vi alle hadde vært redd for endring, hadde vi vel alle vært stuck på klassekomponenter?
Se foredraget hans her:
Refaktorering med sunn fornuft
Kode blir sjelden uforståelig fordi én person overkompliserer noe. Heller er det flere personer over lang tid som har gjort små endringer for å fikse en bug eller lagt til ny funksjonalitet.
Dette gjelder CSS så vel som andre teknologier, og for å hjelpe oss i React har Alex Kondov skrevet en rekke tips for å refaktorere koden. Dette er sårt trengt, ettersom jeg videreutvikler funksjonalitet fra et hackaton.
Her er 5 av de mange tipsene han kommer med:
- Start med en blackbox-test, så du vet at komponenten gjør de samme kallene og spytter ut det samme som før
- Bytt ut kompleks datahentings-kode med mer leselige API-er fra biblioteker som react-query
- Mange useStates i en komponent er tegn på at komponenten gjør for mye, så del den opp i flere komponenter
- Fjern unødvendige states. Hvis “showLoadingIndicator” alltid vises samtidig med “isLoading”, kan du heller bare beholde den siste
- Om du betinget viser store klumper med JSX, putt klumpene i egne komponenter eller lag mer granulære betingelser
Overrasket over første State of React: – Bare to prosent er misfornøyd!
101 tips til bedre React-kode
For å unngå uforståelig kode over tid, bør vi følge gode kodepraksiser fra start. Heldigvis har Ndeye Fatou Diop samlet 101 tips for bedre React-kode, fra named exports til anbefalte biblioteker.
Det var også flere refaktoreringstips her, som å bruke codemod, som automagisk refaktorerer koden. Dette kan være veldig nyttig når du migrerer over til å bruke React-kompilatoren, så du med én kommando fjerner alle nå overflødige memoiseringsfunksjoner.
Før du blir overveldet av 101 tips, anbefaler jeg deg å åpne “table of content” i artikkelen, og titte på kategoriene du er mest interessert i. For eksempel var det flere gode tips for state-håndtering, noe som hjelper deg å holde en komponent leselig.
Det var alt for denne gang. Sees neste uke!