'Tykkää'-painike reagoi välittömästi, sydän täyttyy, laskuri kasvaa – ennen kuin palvelin on edes vastannut. Tämä ei ole mikrointeraktioartikkelin nopeuden illuusio, vaan jotain pidemmälle menevää: käyttöliittymä näyttää tilan, jota ei vielä ole olemassa, ja olettaa, että se kohta on. Tarkastelen, miten tämä rakennetaan turvallisesti – aidolla perääntymisellä valheesta, kun oletus ei pidäkään paikkaansa, ja miksi käsin kirjoitettu setState plus catch on huonompi versio siitä, mitä useOptimistic tarjoaa.
Apuluokka .mt-4 häviää säännölle .card .card__header .card__title, vaikka sen loogisesti pitäisi voittaa, koska se lisättiin myöhemmin. Tämä ei ole sattumaa – tämä on spesifisyys, joka tekee juuri sitä, mitä varten se on suunniteltu. @layer tuo täysin uuden akselin konfliktien ratkaisuun, joka toimii ennen spesifisyyttä, ei sen rinnalla – ja siinä on yksi sudenkuoppa niin epäintuitiivinen, että sen rikkoo jopa osa verkon dokumentaatiosta.
'use server' näyttää pelkältä syntaktiselta sokerilta fetch-kutsulle API-reittiin – ja juuri siksi useimmat toteutukset kohtelevat sitä kuin tavallista funktiokutsua. Tämä on virhe, jolla on konkreettisia seurauksia: jokaisesta 'use server' -merkinnällä varustetusta funktiosta tulee julkinen päätepiste verkossa, ja tähän mekanismiin rakennettu lomake toimii jopa ennen kuin JavaScript ehtii latautua. Tarkastelen, mitä tämän direktiivin alla oikeasti tapahtuu, ja missä piilevät sudenkuopat, joita dokumentaatiosta ei ensi silmäyksellä huomaa.
Lomakekentän pitäisi korostua punaisena, kun sen sisällä oleva input on virheellinen. Yksinkertainen asia – paitsi että CSS ei 25 vuoteen kyennyt kysymään elementiltä, mitä sen sisällä tapahtuu, vain päinvastoin. Tarkastelen, miten :has() kääntää tämän suunnan, miten se eroaa tavallisista kombinaattoreista ja missä tämä uusi voima todella maksaa suorituskyvyssä.
Sama tuotekortti näyttää hienolta ruudukossa ja hajoaa kapeassa sivupalkissa – huolellisesti valituista media querysta huolimatta. Ongelma ei ole koodissasi, vaan siinä kysymyksessä, jonka media query esittää: näytön leveydestä, ei siitä tilasta, jonka komponentti todellisuudessa sai. Tarkastelen, miten container queryt siirtävät tämän kysymyksen sinne, missä sen olisi pitänyt olla alusta asti, ja mitä konepellin alla oikeasti tapahtuu, kun elementistä tulee "kyselysäiliö".
Oikea HTML on vasta lähtökohta. Katso, miten saavutettavuuspuu oikeasti toimii, miksi ARIA aiheuttaa haittaa useammin kuin luulisit, ja rakenna kanssani oikea accordion, live-region ja fokuksenhallinta Next.js:ssä.
