[jameslk]

It's refreshing to see a major release of a frontend library that doesn't completely redo the API (React Router and Angular, take note). I remember there was a time when a bunch of features were being considered to be bolted on to JSX which was going to be called JSX 2.0[0]. I'm glad that never happened. Maybe the next version of React can even remove features, like hooks.

0. https://github.com/facebook/jsx/issues/65

[sophiebits]

I'd bet a lot of money that the next version of React will not remove Hooks.

[acemarke]

I'd still _loooove_ to have "prop punning", ie, shorthand passing of props based on local variable names equivalent to ES6 object literal shorthand:

    <MyList items selectedItem onItemClicked />

Doesn't seem too likely to happen at this point, though.

[jameslk]

While not as sexy, you can do:

    <MyList {...{items, selectedItem, onItemClicked}} />

There's a lot of "gets you most of the way there" hacks with JSX that will fill most needs. Where as you can imagine the incredible cacophony of screaming developers who maintain TypeScript, Preact, IDEs, etc. that would be incensed by breaking changes to JSX introduced just to solve some inconveniences.

[acemarke]

Trust me, I'm well aware of both of those facts :)

Doesn't mean the syntax _can't_ change . After all, the `<>` shorthand syntax for fragments was added via cooperation with the Babel and TypeScript teams, and the work on the new `jsx()` replacement for `createElement()` is going the same way.

[Gaelan]

That conflicts with HTML syntax, no? <input disabled /> is equivalent to <input disabled={true} />.

[acemarke]

Which is why the current JSX syntax uses that as a synonym for `disabled={true}`. Agreed that it matches HTML better, but having written an awful lot of `someLongVariableName={someLongVariableName}`, I sure wish I could stop repeating myself there.

[floydnoel]

I, too, find it ridiculous to repeat `foo={foo}` over and over again. So I use the spread operator with ES6 shorthand object syntax. Now it’s `{...{ foo }}`. No breaking changes needed!

[efrafa]

That would just be confusing.

What would happen with <input disabled /> then?

What if there is a global disabled var?

[tW4r]

I agree, I think <Element {prop} /> works better

[azangru]

I thought this style was generally disfavored? It's perfectly possible to pass `true` as a valueless prop (<MyComponent disabled />); and yet either the default typescript linter, or typescript itself (I never investigated) complains of this syntax.

[scns]

ReasonML works like that

[steve_adams_86]

Do you actually think hooks are worth dropping? I see the appeal of classes, but I really enjoy hooks too.

[jameslk]

I think they're better off as a separate library (similar to react-transition-group), as someone else has suggested in the comments. There's certain cases where they come in handy, I understand this, but they didn't need to be baked into React.

I really dislike the way they can be abused to litter state and side effects all over React code so easily (e.g. hiding it layers deep in helper functions). And I feel they've made the API worse, such as `this` being replaced with the more clumsy `useRef`, or requiring an empty array to change the behavior of `useEffect`. These are things that break the Principal of Least Astonishment and have consequently led to countless blog posts that try to explain how to do things that were much more straight forward without hooks.

I've written about hooks before in past comments: https://news.ycombinator.com/item?id=19357068

It's been a couple of years since they've been added, and I don't feel the ecosystem has improved because of it. So to me it was a mistake.

I know they will likely not be removed from React, so what I said was more tongue-in-cheek.

[hazz99]

This is fair, but I really enjoy using hooks. I personally feel my code is faster to write and easier to understand.

It makes it much easier to have composable functions/state, which I love.

[have_faith]

It's certainly faster to write once you get the hang of it but I don't think it's easier to understand. People seem to converge on multiple useEffect's with anonymous functions with non obvious scope for variables, empty arrays to designate behaviour that isn't obvious, lots of subtle async gotchas, stale state variables, etc.

They certainly work when you memorise the rules and syntax, but it feels very contrived even when it all makes sense.

[steve_adams_86]

> empty arrays to designate behaviour that isn't obvious

This drives me a little crazy too. That behaviour can be easily documented by wrapping it in a function with a name that makes sense, but people litter their React code with non-obvious hooks everywhere. You can reduce a lot of boilerplate (why are you writing empty arrays everywhere!?) and improve readability substantially by wrapping the hooks in more composed and idiomatic functions.

I think that was along the lines of what was intended for hooks, but I don't see it often.