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.
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.
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.
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.
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!
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.
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.
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.
> 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.
0. https://github.com/facebook/jsx/issues/65