Recoil, nytt state management library for React fra Facebook

Nyheter
#1

Føreløpig i eksperimentell fase, men ser veldig spennende ut! Redux utfordrer med mye mindre boilerplate, masse kule features, potensielt bedre performance i noen tilfeller og med planlagt støtte for Concurrent Mode (som kommer en eller annen gang)

Anbefaler å sjekke det ut!

1 Like
#2

Synes recoil ser veldig spennende ut. Det jeg liker:

  • Det virker veldig enkelt, og bygget på noen gode prinsipper (de har som mål at det skal være “simple”, og at det skal virke på samme måte som innebygde react hooks).
  • Det blir litt lettere å refactore state logikk og struktur, dette fordi atoms ikke trenger å kobles inn i applikasjonen på noen måte, annet enn å bare ta de i bruk. Antar det går an å putte atoms ut i pakker uten å måtte gjøre noe spesielt for å få det til å funke (de snakker selv om at thirdparty plugins er et stort use case).
  • Selectors kjører ikke med mindre input endrer seg. Du oppnår det samme i redux med reselect, men med recoil trenger du ikke gjøre noenting. Eneste er om resultatet av selector er likt selv med ulik input, da vet jeg ikke helt hva som skjer. Mulig du må memoisere i sånne tilfeller, og sånn sett er redux+reselect litt tryggere. En ting som skiller recoil fra redux+reselect er at recoil ikke vil kjøre memoiseringssjekken engang om input ikke har endra seg, så hvis du har ekstremt mange selectors vil det potensielt bli bedre perf (men tviler på om det har noen praktisk betydning).
  • Mindre boilerplate enn redux fordi det ikke er noe skille mellom action og reducer.
  • Selectors er veldig powerful. Du kan til og med ha en setter på en selector, som da kan brukes til å oppdatere atoms upstream. Selectors støtter også async + caching direkte, og erstatter dermed redux thunk og til en viss grad redux saga.

Det er et par ting som kan være skjær i sjøen også:

  • Selectors må være “pure”. I gåseøyne fordi de ikke egentlig er pure (de støtter async), men de må alltid returnere det samme gitt lik input. Det betyr at dersom du gir den samme input vil den bruke cache’n. Hvis du da putter inn en async funksjon for å laste inn data vil ikke denne bli kjørt mer enn én gang. Samme om du bruker andre ting som feks new Date(). Måten man løser dette på er ved å gi selectoren ny input, feks ved å ha en dummy request id som øker monotont hver gang du vil laste på nytt. Her kunne de kanskje tatt inspirasjon fra diverse funksjonelle språk som har det samme problemet. Uansett, her er det en tradeoff mellom hvilke defaults som passer i ulike scenarioer. Det som er digg er at du hindrer innlasting av data som allerede er lastet inn som default.
  • Du kan ikke kjøre selectors utenfor react. Dvs, hele opplegget lever bare innenfor react, og er sterkt knyttet til react. Hvis du ønsker å feks laste inn data via en selector fra en funksjon på utsiden av react må du lage en dummy react komponent som lytter til en ekstern event, endre state i en atom når du får en event, og dermed trigge ny kjøring av selectoren. Antar at de fikser det etterhvert, det er alllerede noen issues på det.
  • Reduksjonen av boilerplate kommer antakelig med en kostnad i form av mindre fleksibilitet. De use-casene recoil støtter vil bli langt diggere enn med redux, men skal du gjøre noe som krever mer fleksibilitet tror jeg det vil bli smertefullt.

Er sikkert mye mer som jeg ikke har fått med meg enda (både pros/cons). Gleder meg til å teste det!

1 Like
#3

Veldig bra oppsummering!

Det jeg kanskje ikke liker er at det føles som om det blir en del skjult magi, som i beste fall fjerner noe fleksibilitet (som du også var inne på) og værste fall blir veldig vanskelig å debugge, eller fører til spaghetti. Foreløpig mangler devtools, men det kommer sikkert også etterhvert.

En annen ting med redux som er veldig digg er time-travel (spesielt på global state), dette kan man helt sikkert løse i Recoil også, men har ikke prøvd/gravd nok til å vite hvordan evt.

Sikkert enda flere fordeler og ulemper også, men dette ser iaf ut som et nytt lovende verktøy å ha i kassa :smiley: