React Blog

> React pre and post 16.8 are two completely different libraries.

The two apis still coexist within the same library.

> The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.

That is exactly what I mean by the word "alternative". As in, previously, you achieved certain results by calling componentDidMount/DidUpdate methods; now, in order to achieve same results, you would use the useEffect in a certain way.

> Update the state during render? what?

See "Adjusting some state when a prop changes" section of "You Might Not Need an Effect"

> if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref

Sure. But what if during a render you want to check something in the DOM (geometry of a DOM node or something). I do not think that pre-2019 there were any guidelines that you mustn't. There weren't any such recommendations after the hooks were released either, when all we had to go by was the hooks api documentation in what now is the legacy documentation site [0]. The caution against doing this only appeared in the new react docs in 2022. My point here is that the docs change, and the patterns of usage of the library change, and what was considered ok once no longer is.…

I think you're hung up on JSX being HTML - it isn't HTML and doesn't try to be. The "JS" stands for "JavaScript" and the "X" stands for XML, not HTML.

> However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?).

Yes, it's not HTML or JS, it is JSX. It's an XML-based syntax to declaratively write JavaScript. It's optional too - one can write the function calls directly in JS, and indeed that's what people did before JSX existed. `React.createElement("div", React.creatElement("span"),...)`. It could be worth using a REPL [1] to gain an intuition of the JavaScript that is produced from transforming different JSX examples.

> The result is, that one has to learn some different syntax that is specific to React.

JSX was originally created for React, but now is not specific to React, other libraries and frameworks use it as well. It's a general purpose XML-based syntax for writing JavaScript declaratively.

And yeah, if you want to use JSX you have to learn it. It's easy to learn if you know JavaScript and XML and shouldn't take very long. It's XML and then anything inside curly braces is a JavaScript expression.

If you're using TypeScript replace everything "JS" I'm saying with "TS", it's the same result. And obviously type checking works without issue because it's a syntactic transformation to TS, not a semantic transformation.

> In a…

> None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago.

Hooks are ~~7~~ 6 years+8months old, almost 7 years. This may not seem like a significant difference, but IMO it puts them 75% of the way back in time to when react took off versus 50% of the way. That is a significant difference. Please stop repeating the 5 year number. It's _provably_ wrong and not a matter of opinion: https://legacy.reactjs.org/blog/2019/02/06/react-v16.8.0.html

> does not seems like something a stable ecosystem would do.

I don't think being a 'stable ecosystem' means owning every part of the dev process, or even most of it; nor have they ever intended to do so (they didn't reimplement npm, webpack, etc). CRA existed to fill a particular need for a time (providing a simpler/more stable interface in front of webpack), and when that was no longer needed by the community, they abandoned it. I don't understand why this matters. Better tools emerged, the React docs/guidance reflect that.

> because I inherited a simple site that should have never used React

I'm sorry that you're in that situation. The React community is not really responsible for that IMO, and I don't think the things you've highlighted have meaningfully contributed to making that worse. I stand by the fact that deprecating CRA once great…

I can objectively prove that React devs themselves have at the very least changed how they understand hooks but more likely have been making it up as they’ve gone along. The best example is one of the more problematic hooks, useEffect.

Here’s how useEffect is described in the old documentation:

https://legacy.reactjs.org/docs/hooks-effect.html

> The Effect Hook lets you perform side effects in function components

Here’s how the new docs explain useEffect:

> useEffect is a React Hook that lets you synchronize a component with an external system.

These are dramatically different claims about what useEffect is supposed to be for. Dig a little deeper and Reaft developers will now explicitly tell you to not use useEffects for side effects, which again is the opposite of what they explained it to be.

The same change in how they’re actually supposed to be used has been true across all the books to a lesser or greater degree.

Maybe React has finally stabilized and it’s easier for new devs because they’re learning the more stabilized version. However, I suspect it’s easy because they just happen to be within the same cycle of understanding in React. Much like how React was easy for devs coming to it nearly a decade ago, until the devs changed everything about it. New devs may just not be deep enough into the new cycle to experience the pain of all your understanding being wrong.

Now, to be completely clear, I have no problem with the changes. I think change is good and I…

> Note that is also possible to create a new properties and signals for the Text which can be referenced by the children

This behavior exists without inheritance as well! Let's imagine we want to use our existing `HelloText` component. But like you suggested, let's subscribe to the `onclick` signal and add a `bolded` property. When the user clicks the text, it will toggle the bolded property. We will use React because it's famous for not using inheritance.

```jsx
function HelloText(props)
{
return <Text
{...props}>Hello World!</Text>;
}

export default function App()
{
const [bolded, setBolded] = React.useState(false);
return <HelloText onClick=
{() => setBolded(bold => !bold) bold=
{bolded}} />
}
```

And just like you wanted, even children of `<Text>` could reference `bold` and `onClick`. I'll assume you know what that would look like. If not, let me know and I'm happy to make examples for that too. You can provide default prop values that can be overridden. You can accept functions. You can expose signals.

If you are being attentive, you might have noticed the code that enables this behavior: `
{...props}` is the explicit way to pass all the props from the parent `HelloText` to its child `Text`. Unlike React, exposing props is implicit and automatic in QML. Though its trivial to make every component expose all their props to their children, the docs argue that you should avoid this. They say that if you find yourself doing this a lot, you are probably…

It’s very clear useEffect was created with a certain purpose and then the React folks realized that was a terrible use of it and changed the purpose of useEffect.

And this would have been fine if they had been upfront about how they were wrong about useEffect and how now this is the correct way to do it. But instead, they’ve at best kept silent about this transition, and a lot of people strongly attached to React have decided to gaslight everyone else about useEffect (I’m a huge React fan… it’s my default UI library but that doesn’t mean I’m ok with gaslighting over transparency).

And the easiest way to prove this is to compare the docs.

Original:
https://legacy.reactjs.org/docs/hooks-effect.html

> The Effect Hook lets you perform side effects in function components:

New:

https://react.dev/reference/react/useEffect

> useEffect is a React Hook that lets you synchronize a component with an external system.

Synchronizing with an external system is completely different behavior from performing side effects. And we know the original intention was to perform side effects and not sync with external systems because the name of the hook is useEffect and not useSyncExternal.

Unless the React team always had the new intention but deliberately decided to mislead everyone through the original documentation and by misnaming the hook, but I don’t think even the biggest React hater thinks so poorly of them, and I’m a fan.