Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to write PureScript react components to replace JavaScript

thomashoneyman.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: How to write PureScript react components to replace JavaScript

#61

Post by acemarke »

Softcadbury wrote: post #20
Cthulhu_ wrote: post #18

Earlier quoted context omitted.

Pedantic and what always happens when someone posts code on the internet, but, I'd extract the onClick function and provide a default value for the onclick parameter for readability, and use cleverness to show off: export const Counter = ({label, counterType, onClick}) => { const [counter, setCounter] = useState(0); onClick = onClick || () => {}; const handleClick = () => { const modifier = counterType === "Increment…

You should also use useCallback for handleClick

Not in this example, no. There's zero benefit to memoizing a callback that's passed to a "leaf/host" element like a `

See my extensive post "A (Mostly) Complete Guide to React Rendering) for details:

https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Re: How to write PureScript react components to replace JavaScript

#63

Post by myth_drannon »

slifin wrote: post #33
edjroot wrote: post #32

Earlier quoted context omitted.

Awesome! Would you mind talking some more about your experience with it? I just got started with Clojure and Fulcro[1] (a full-stack framework) and I'm really, really excited about the possibilities. Have you heard about it? Here are some features off the top of my head (at least that's what they claim): - Well-integrated stack, so very little friction - “Datomic on the front end”: Client-side time-traveling database…

I'm making this same journey (I'm on video 5), and I'm making some notes for each video in Roam and teaching/learning each video every week via Google Meet on Bristol's Clojure Meetup I recommend using clj-kondo to catch the kinds of silly mistakes a type system is usually good for, yesterday we discovered that the react component interop is really good, we decided to try using https://chakra-ui.com/ over semantic ui…

>I'm making this same journey (I'm on video 5) >

Sorry, which videos are you watching?

Re: How to write PureScript react components to replace JavaScript

#64

Post by [deleted] »

chvid wrote: post #3

This is the corresponding code written in React using hooks: export const Counter = ({label, counterType, onClick}) => { const [counter, setCounter] = useState(0); return ( { counterType == "Increment" && setCounter(counter + 1); counterType == "Decrement" && setCounter(counter - 1); onClick && onClick(); }}> {label}: {counter} ); } I think the case for PureScript React would be more convincing if the code you ended…

[deleted]

Re: How to write PureScript react components to replace JavaScript

#65

Post by jamil7 »

BFatts wrote: post #57

Do we need another strongly typed language that compiles to JavaScript? If that's so important, why don't people use C/C++ and compile that to WASM for best performance too? We've got TypeScript... is it necessary to have yet another language??

Purescript is from a different family and has different goals. Overall though more languages and more choice is a good thing. Typescript (I'm thankful it's around) is just the path of least resistance and has therefore become the defacto.

Re: How to write PureScript react components to replace JavaScript

#66

Post by e12e »

michaelcampbell wrote: post #42

I admire his CLI approach to things, but this just seems dogmatic: echo -e "\noutput\n.psc*\n.purs*\.spago" >> .gitignore Sure, ok, saying "add these entries to your .gitignore" is too pedestrian?

At least I'd prefer a simple here-doc:

  tee -a .gitignore
(or use:

  cat > .gitignore
  output
  .psc*
  .purs*
  .spago
  EOF
But I think the tee-version more readily emphasize what's going on, and works with sudo).

Re: How to write PureScript react components to replace JavaScript

#67

Post by e12e »

rkangel wrote: post #55
edem wrote: post #23

Why would anyone write purescript when we have typescript?

I would phrase the question as "why would you write Typescript when we have Purescript (or ReasonML)"? Why would you choose to write a language who's type system is much less expressive than languages like Purescript? Why not have that expressive power and its ability to prevent some classes of bugs, and still have good interop with JS?

I was actually thinking, why would you use purescript for react, when you could use reasonml?

https://reasonml.github.io/reason-react/docs/en/components

https://reasonml.github.io/reason-react/docs/en/usestate-eve...

As far as I can tell the integration is cleaner and has better support from upstream? I guess it's not Haskell - but I really would be interested in why you would choose purescript for this use-case (personal preference is a fine reason, but I'd at least hope that preference goes beyond merely syntax?).

Re: How to write PureScript react components to replace JavaScript

#68

Post by lalaithion »

diggan wrote: post #36
noelwelsh wrote: post #24

Earlier quoted context omitted.

FWIW here's a Purescript example from the `purescript-react-basic-hooks` homepage[1]. It's not 100% identical but it is fairly close. mkCounter :: Effect (ReactComponent {}) mkCounter = do component "Counter" \props -> React.do counter /\ setCounter show counter ] } Your aesthetic / background may differ from mine, but I find the Purescript version easier to read. [1]: https://github.com/spicydonuts/purescript-react-…

Not sure I misunderstand the code that you're posting, but seems to not have the whole increment vs decrements parts in it, which would be interesting to see.

This is a closer comparison.

    mkCounter :: String -> (Int -> Int) -> Effect (ReactComponent {})
    mkCounter label op = do
      component "Counter" \props -> React.do
        counter /\ setCounter  ": "  show counter ]
            }
now you can call

    mkCounter "Increment" (_ + 1)

Re: How to write PureScript react components to replace JavaScript

#69

Post by filoeleven »

CraigJPerry wrote: post #45
diggan wrote: post #25

Earlier quoted context omitted.

Did someone say concise? Here is a ClojureScript + Reagent example for whoever is interested in that: (defn Counter [{:keys [label counterType onClick] :or {onClick (fn [])}}] (let [count (r/atom 0)] [:button {:onClick #(do (swap! count (condp = counterType :increment inc :decrement dec)) (onClick))} (str label ": " @count)])))

There's something attractive about this example but i'm struggling to figure out why i think that. What is it that makes this attractive? + There's a signal to noise ratio that's off the charts + You've not cheated to achieve succinctness; there's no blackbox.nowDrawTheRestOfTheOwl() - I don't think that's "pretty" code - i don't find it easy to parse, i had to read your example with my index finger pressed against t…

Just curious: what’s your level of fluency with Clojure/lisp syntax vs C-style syntax?

I found that learning to read the lisp-style indentation (which is purely by convention but has widespread acceptance and tooling support) was a pretty fast process with a solid payoff. It becomes easier to jump between levels of detail, and I now find it to be more readable than C-style syntax, even though I only write JS for work.

For example, in the code above, “what it does“ is made clear by reading downward without looking very far to the right: it draws a button with a click handler and a label. There is a guarantee offered by immutability that says “anything deeper than my current level cannot affect things outside of itself.”

That may sound like a lie, since the :onClick handler updates an atom, but knowing that a dereferenced atom (@count) has a stable value during the lifetime of the function call resolves it.

I don’t know how strong that guarantee is with other lisps; I think Clojure’s immutability plays a key role though.

Re: How to write PureScript react components to replace JavaScript

#70

Post by oweqruiowe »

oweqruiowe wrote: post #47
diggan wrote: post #25

Earlier quoted context omitted.

Did someone say concise? Here is a ClojureScript + Reagent example for whoever is interested in that: (defn Counter [{:keys [label counterType onClick] :or {onClick (fn [])}}] (let [count (r/atom 0)] [:button {:onClick #(do (swap! count (condp = counterType :increment inc :decrement dec)) (onClick))} (str label ": " @count)])))

I use Clojurescript professionally and it has the best state management story with re-frame over JS and any transpile-to-js language. It's so lovely.

To expand, I love this document even from the standpoint of how to structure client-side code http://day8.github.io/re-frame/application-state

It applies to React/Redux folks as well.

> There are benefits to having data in the one place:

> Here's the big one: because there is a single source of truth, we write no code to synchronise state between many different stateful components. I cannot stress enough how significant this is. You end up writing less code and an entire class of bugs is eliminated. (This mindset is very different to OO which involves distributing state across objects, and then ensuring that state is synchronised, all the while trying to hide it, which is, when you think about it, quite crazy ... and I did it for years).

> Because all app state is coalesced into one atom, it can be updated with a single reset!, which acts like a transactional commit. There is an instant in which the app goes from one state to the next, never a series of incremental steps which can leave the app in a temporarily inconsistent, intermediate state. Again, this simplicity causes a certain class of bugs or design problems to evaporate.

Post reply on HN