> React is mostly HTML driven by data.

I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream.

I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frameworks adopted these ideas. It’s great that React established them. It’s just a bit sad that React established them.

▲

webstrand a day ago | parent | next [-]

I thought the way React did suspense was pretty elegant?

The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.

	▲	recursive 21 hours ago \| parent [-]
		It only achieves purity by re-defining the pre-existing concept of "pure". Component state is not passed as an argument, and can affect the output of a render function. It's only by playing semantic games that react claims to be pure, which I find to be of dubious value in this domain anyway.

▲

rimunroe a day ago | parent | prev [-]

> pedantic docs

Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.

▲

iammrpayments 14 hours ago | parent | next [-]

This is the most pedantic section for me, it’s just a bunch of 5 year old illustrations with 0 explaining on how React actually works behind the scenes: https://react.dev/learn/render-and-commit

	▲	rimunroe 13 hours ago \| parent [-]
		Sorry, what’s the pedantic part of this? I don’t think I’m understanding what you mean by that word here. Do you mean that the information isn’t useful? This page is explaining the process React takes when rendering, the general version of which hasn’t really changed since it was released. There are differences in things like Suspense and SSR, but it’s broadly the same. Knowing the difference between render and commit phases is important for other parts of the docs to make sense. What sort of behind the scenes workings would you want explained here?

▲

skrebbel a day ago | parent | prev [-]

Yeah stuff like useEffect which is supposedly a function that "lets you synchronize a component with an external system" [0]

So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?

Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.

This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.

useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.

And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.

[0] https://react.dev/reference/react/useEffect

	▲	rimunroe a day ago \| parent [-]
		What's the condition in which you're trying to focus that input? Usually you're doing that in response to some sort of user action, in which case the time to handle that is within an event handler. > And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell. Further down in the docs you'll see[0]: > Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case. [0] https://react.dev/reference/react/useEffect#wrapping-effects...