News for hackers. Stuff that matters.
Re:Thinking in React Hooks by ng12 on Thursday December 12, 2019 @11:19AM (#21773189)
I don't think this is a compelling example. React would implement this almost identically:

    const Counter = () => {
      const [count, setCount] = React.useState(0)
      return (
        <div>
          <p>You have clicked the button {count} times.</p>
          <button onClick={() => setCount(count => count + 1)}>Increment</button>
        </div>
      )
    }
Replace the atom/swap with a useState hook and it's almost identical.
Re:Thinking in React Hooks by jmiskovic on Thursday December 12, 2019 @01:58PM (#21775017)
The difference is in how the state is handled. In Clojure, it is contained in an atom, which is a well documented language primitive which can change value in controlled manner. It's not some magic construct hidden behind innocently looking JS function useState().
Re:Thinking in React Hooks by dhucerbin on Thursday December 12, 2019 @02:32PM (#21775407)
To be fair, reagent uses it's own implementation that satisfy atom protocol. And it uses some funky magic with keeping derefs and triggering rerenders. In principle, as atom is idiomatic Clojure, setState is idiomatic javascript. ratoms and hooks both add some sugar to it.
Re:Thinking in React Hooks by pgt on Thursday December 12, 2019 @06:33PM (#21777714)
`setState(...)` is not idiomatic in JavaScript.
Re:Thinking in React Hooks by dhucerbin on Friday December 13, 2019 @03:26AM (#21779994)
I'm not sure how far back you want to go, but `this.set` is used in most frontend frameworks, starting around knockout and backbone. You had object which managed state for you (then it was model, today it is component) and it had some setter method.
Re:Thinking in React Hooks by ArchReaper on Thursday December 12, 2019 @06:36PM (#21777733)
React is open source, you can view the source for this "magic construct" so I don't see any validity to your argument.

useState returns 2 variables - a getter and a setter, where the getter is just a variable and not even a function to call.

How is that equatable to some hidden construct? How is Clojure superior to that?

Re:Thinking in React Hooks by mondaygreens on Thursday December 12, 2019 @11:27AM (#21773256)
Yeah that's way more readable and intuitive than anything that came before (that I'm aware of)!
Re:Thinking in React Hooks by kgwxd on Thursday December 12, 2019 @12:00PM (#21773637)
1 language vs 2 intertwined languages is compelling enough for me.
Re:Thinking in React Hooks by ng12 on Thursday December 12, 2019 @12:09PM (#21773740)
Do you mean JSX? Here you go:

    import {createElement as h} from "react"
    const Counter = () => {
      const [count, setCount] = React.useState(0)
      return h("div", {},
        h("p", {}, `You have clicked the button ${count} times`),
        h("button", {onClick: () => setCount(count => count + 1)}, "Increment")
      )
    }
There are additionally libs like hyperscript (https://github.com/mlmorg/react-hyperscript) that take the non-JSX approach further. Although honestly, I don't recommend it. JSX is really great even it seems a little unfamiliar.
Re:Thinking in React Hooks by ArchReaper on Thursday December 12, 2019 @06:33PM (#21777712)
What? JSX allows you to write HTML as though you are actually writing HTML.

The '1 language' version requires you to learn language-specific syntax for creating HTML elements.

How is that more compelling?

Re:Thinking in React Hooks by pgt on Friday December 13, 2019 @02:57AM (#21779885)
(not= syntax semantics)