React I love you, but you're bringing me down

Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted.

> Form libraries are portly maintained or documented

The two-way data binding in Svelte saves ~4 lines of reusable hook function but doesn’t come close to covering defaults, validation, errors, dependent fields etc - all of that is essential complexity.

Write your own form field hook. The state model for a form is simple - what is a 3rd party library bringing to the table in terms of state management? I have more pain explaining what I want to a 3rd party library than I do writing a bit of code myself to do the same thing. I reach for open-source input components from a vendor for things like credit cards, but manage the state myself.

> useContext and useEffect have annoying dependency tracking; I prefer Solid’s mutable state and automatic dependency tracking.

React’s built-in hooks are positioned as building blocks with clear-cut contracts. Why dump Redux for bare useContext if you prefer Redux’s selectors? Just use Redux. If you like the Solid style of automatic dependency tracking and mutable state, just use Mobx - it’s a mature library for that style that’s been around for 7+ years, and is used in production by products like Linear and Cron.

Overall I agree that function components in React are difficult to get right for developers and a bit too verbose. There’s an onboarding tradeoff to every abstraction you layer over the framework’s APIs, but there’s large advantages too. Do so judiciously to find the sweet spot for your team & scale.

Agree with a lot of this, but, some quibbles:

1. yes, un/controlled forms are messed up and need work

2. yes, contexts should replace Redux and Redux should go away. but in practice having a few contexts is pretty manageable. Currently we use Redux for all the dynamic state and contexts for everything else and it works pretty well. It is quite easy, also, to write your only little `useSelector()` wrapper around a non-mutating context value (ie: the context has a callback on changes, you listen and filter updates, then update a `useState` to trigger rerender)... but but maybe this a bit too abstract to actually want to do.

3. yes, forwardRef is silly.

4. yes, useEffect is kinda broken. My main issue which wasn't discussed much here is that the difference between `useEffect(..., [])` and `useEffect(...)` is insane. The latter should not exist, or have a different name entirely.

Otherwise, I really don't mind tracking deps _that much_, although I hate that it's hard to have an effect that updates 'on some local variable changes but not others', so in practice I pretty much ignore the lint warnings all the time.

It all feels like "there's a DSL waiting to be written for this stuff, similar to how JSX makes createElement() more ergonomic, but it doesn't exist yet".

That said, Solid doesn't seem like the answer. Solid's even worse: now you're using JSX for if/else statements, instead of the actual DSL you want that doesn't exist yet. Good luck running a debugger on that. (Although actually, if the Solid AST ends up in the Devtools view, that's pretty good. But still: this needs a fully-featured DSL).

5. +1, yeah, the continuing addition of weird hooks feels like a mistake that will eventually be regretted.

6. The right way to do your Inspector example is to have a parent component that decides whether it's rendered, and a separate child which does all the event listeners. It is a bit weird to me that React doesn't allow this to be done in one place. The closest thing is defining another component inline in the first one and then immediately rendering it. But for readability it's best to just have two separate components.

7. +1 to old docs getting in the way. I'd love to see a React 2 with a new name that deletes all the class component stuff entirely so that all of the docs about it are up-to-date. I've been toying with trying to work on this myself.

8. Yeah, fuck FB

9. Yeah, I'm not going to any of the other frameworks either. React is great, it's just ... not... great enough. I am in the middle of writing a series of blog posts about exactly this and I haven't finished yet but anyway here's the first one that I have written about why I like it so much? https://alexkritchevsky.com/2022/09/17/react.html

Regarding the Inspector/isVisible complaint:

When you want to have "early return" in a component, it's possible to just split the component into two to introduce an "inner" component that contains whatever comes after the early return point in the original component.

Any local variables from before the early return then need to be passed as props to the new inner component.

However, naming this inner component is always an issue for me. Typically I just name them Inspector2, Inspector3, etc. until I have an implementation that works. Then I can start thinking about how to refactor the implementation into something that I can give sensible names.

It's really a code transformation similar to async/await where you derive a state machine from a block of code by identifying transition points. In async/await you have transitions at the await points; in components you have transitions at the early return points. In async/await, no one is forcing you to name the individual states or even write them out explicitly - the compiler takes care of it. Then why do I have to write out the state machine explicitly and name the states explicitly for function components with early return? I would love for React to have some facility like "Consider the rest of this component as a new sub-component; as if this component now returns a single Element pointing to whatever is in the rest of this component". But it's probably a Hard Problem™.

That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…

I spent about 2 years at my last job building a greenfield react app mostly by myself (around 10k sloc). I enjoyed it for the most part. But I did run into all the issues raised here, they are valid. I think the worst issue with React is the dependency arrays that get sprinkled around everywhere - in my opinion the framework is unusable without a 3rd party linting tool that points out when your dependency array is missing something. If you accidentally add the wrong value in there, hello infinite render loop!

One of the biggest level ups I had was extracting complex hooks into their own .js files instead of stuffing next to component code. This helps a lot with readability/reusability.

Overall I liked what I came up with, but it felt like a lot of inventing stuff on my own, which I'm not sure if the next developer who comes along will appreciate.