Jeg gjør for tiden et forsøk på å få overtalt kolleger om at dette:

useEffect(lastGreierFordiJegTilfeldigvisDukketOppIDOM,[])

Når jeg startet min IT-karriere så hadde react-miljøet tilstandshåndtering og side-effekter via redux, som tross sine begrensninger må kunne sies å ha fasilitert bedre frontend-kode enn dette? Skjønner liksom ikke hvor det ble av, men det henger sikkert sammen med at React har prøvd å gjøre seg selv til å handle om mer enn bare et rendering

For et par uker skriven refaktorerte jeg en useEffect som inneholdt 100 linjer kode, etter å ha delt den opp i funksjoner fant jeg i ut at nesten halvparten ikke var nødvendig, og endte i tillegg opp med å halvere antall renders i appen. Leser faktisk Grokking Simplicity også nå, og bare den actions, calculations og data inndelingen er en utrolig nyttig tankemåte. Her er min erfaring og tanker som noob som kom inn i web-verdenen akkurat når Redux var stort men også på vei ut: Redux kom(mer) med sine egne problemer: 1. Bratt læringskurve 2. Stort krav til arbeidsminne (actions, reducer, original komponent generelt mye kode). I tillegg tror jeg ofte react komponenter starter sitt liv med en enkel useEffect, også utvikler prosjektet og koden seg til å ende opp med 3-4 stykker. Det vel react query som har erstattet mye redux? I tillegg er det spennende ting man kan gjøre med kombinasjonen react-router + react-query.

@UDB2Q0W13 nå er ikke jeg noen hooks-ekspert, men jeg er overbevist om at redux la opp til dramatisk bedre arkitektur, ja

@UDB2Q0W13 Hvordan prøver du å overtale dem? Hva er alternativet du skisserer?

Det skal sies at jeg personlig ikke er 100% bestemt på det beste alternativet da, men gitt at jeg tenker at redux også var et fullgodt alternativ, så argumenterer jeg gjerne som om det er dit vi burde gå. Og så er kanskje ikke alle argumenter like gjennomtenkte! Men siden du spør så kan du få mange ustrukturerte tanker 😅: • Komponenter burde i minst mulig grad være ansvarlig for å gjøre nettverkskall eller andre side-effekter. Det gjør det vanskelig å sette opp visuelle frontend-tester i feks Storybook (@U9MKYDN4Q sin Javazone-presentasjon viste jo at man kan putte nesten hele applikasjonen med ulike tilstander i Portfolio) • Hvis komponenter må være ansvarlig for side-effekter så burde de isåfall dispatche en eller annen event/action (da kan den frakobles “servicelaget” i frontenden, og trenger ikke å vite om det heller) • Hvis komponenter skal ha data så burde de komme inn via props (ikke useContext, jeg er ørlite mer pragmatisk til useState) Men det viktigste med reglene over må vel være hva man oppnår, og da tenker jeg at man feks oppnår • Enklere testing av visuelle endringer (kan laste nesten hele appen i feks Storybook i stedet for å måtte trykke seg rundt for å finne riktig tilstand for å sjekke endringen) • Enklere oversikt over hva som faktisk skjer i applikasjonen (Redux hadde et visuelt utviklerverktøy som viste actions som ble fyrt av i appen og hva slags tilstand man endte opp i) • Enklere å flytte rundt på komponenter i DOM (må ikke sørge for å også flytte rundt på “contextprovidere” og lignende som kanskje ligger i en “branch”, men ikke en annen) • Lavere skuldre med at man har mer kontroll over når ting skjer (føler at useEffects kan trigge litt når som helst avhengig av hvor raskt et nettverkskall skjer i prod vs lokalmiljø hvis man er skikkelig uheldig. useEffects trigger to ganger med vilje i development-mode for å sørge for at man ikke bruker de helt feil) • Man kan lettere teste forretningslogikk i action->state når business-logikken ikke trigges via en effekt i en react-komponent

Det er vel ikke direkte dårlig design, men det er definitivt en dårlig docstring.

Jeg har ikke tenkt lenge på dette, men siden prisen for å tråkke feil med denne er så høy så ville jeg nesten vurdert å få den til å kaste en exception når ting ikke matcher 😅