Fork me on GitHub
#clojure-norway
<
2022-02-22
>
augustl10:02:24

ok... ærlig spørsmål. Noen her som er veldig fans av cljs, men ikke klarer å finne noen problemer med moderne react med hooks? Jeg er ihvertfall en av de

Jakub Holý (HolyJak)10:02:55

Utenfor JS mener du? :)

isak15:02:09

Det er mange som ikke liker hooks, ikke bare cljs folk. Se her: https://news.ycombinator.com/item?id=22995928

augustl15:02:37

er ganske delte meninger ser det ut til

augustl15:02:46

ser ut som mesteparten av kritikken er ordsalat :thinking_face:

isak15:02:26

Jeg er egentlig enig med den ordsalaten, men det betyr ikke så mye for meg, fordi jeg trenger ikke å bruke det.

teodorlu21:02:23

Synes react og hooks er helt greit - men skulle gjerne sluppet JSX til fordel for Hiccup.

Christian Johansen08:02:58

hooks er dritt fordi det baserer seg på implisitt dataflyt. Do not want

Christian Johansen08:02:04

Implisitt dataflyt er gøy og virker elegant og magisk når ting er smått og oversiktelig og blir et helvete å ha med å gjøre når det vokser (eller du bare ikke er kjent med den implisitte flyten)

augustl10:02:13

interessant! Hva tenker du på som implisitt med hooks? Det er vel nettopp derfor jeg ikke har så mye imot dem, de føles ganske eksplisitte. useContext er en slags hybrid, men du må si hvilken context, og i praksis er dataflyten helt lineær, det er ikke en OO-graf, osv

Jakub Holý (HolyJak)12:02:00

Jeg vil gjerne forstå hva du mener med implisitt dataflyt. Tydeligvis er jeg ikke kjent nok med Hooks til å forstå det...

teodorlu13:02:39

@U9MKYDN4Q anser du Reagent for å være implisitt dataflyt? hvorfor / hvorfor ikke?

Christian Johansen13:02:09

@U0MKRS1FX jeg kan ikke så veldig mye om hooks, men min forståelse er at du bare gjøre useBlabla() inne i komponenten din, og vips, så skjer det noe greier. Du er nødt til å ha noe implisitt global state for at det skal gå an.

Christian Johansen14:02:41

@U3X7174KS ikke implisitt, men det jeg misliker med reagent sin tilnærming er at du ikke har enveis dataflyt. Data kan trigge rendering på et “uvisst” antall steder. Jeg foretrekker å lage frontendapper hvor du smeller sammen all tilstand på toppen, og sender det gjennom én sentral komponent som fordeler utover i et tre. Det er tradeoffs med det også, men det som appellerer til meg er: 1. Dataflyten blir veldig eksplisitt, starter alltid på ett og samme sted. 2. Alle komponentene blir “dumme” komponenter uten tilstand. Dermed kan du lett hive enhver komponent i devcards/storybook, og uten tilstand er det færre steder å bygge inn antagelser som kan gjøre det vanskelig å bruke samme komponent til det som for brukeren er logisk forskjellige ting. 3. Du kan inspisere dataene som brukes for å rendre en side for å få svar på ting. Du kan skrive regresjonstester mot den. Du kan adresse enhver tilstand i applikasjonen med ett stykke data. En ulempe er at all data må sendes nedover, men uten et typesystem som tvinger deg til å navngi alt som “sklir gjennom” opplever jeg ikke dette som noen stor begrensning. En annen ulempe er at alle komponenter med funksjonalitet utover det visuelle må bestå av to ting dersom de skal være gjenbrukbare: en “backend” og en komponent - ettersom komponenten ikke kan ha tilstand, og heller ikke drive nettverk og andre ting som ikke har med rendering å gjøre.

💯 2
teodorlu14:02:14

Det gir mening. Sender du da inn en parameter for å få med deg side-effekter ut? Som :on-change? --- Du fikk meg til å tenke på https://www.kodemaker.no/blogg/2021-11-mer-mindre/, som du vel skrev for noen måneder siden. Og at komponentene kan bli mer gjenbrukbare. Jeg har prøvd å få til noe liknende i Elm. Jeg hadde lyst til å bygge et element med liknende signatur som https://package.elm-lang.org/packages/elm/html/latest/Html#input, men med validering av tall. Da måtte jeg mappe om meldingen på vei "ut" av komponenten.

Christian Johansen14:02:40

Ja, vi representerer side-effekter som data, som det siste eksempelet i den bloggposten 🙂

👍 1