Well there's a cost to that abstraction, e.g. you'd have to pass the context into the component, so every time you need to modify the component's schema/props you'd need to change it twice, both in the parent and the component.
You must have seen some huge React components with 20 different props or even more, and you'd need to think about memoizing those props to prevent a re-render, etc etc.
I've also been a web dev for over 20 years, and 10 years with React. I'd say that going back to native HTML APIs for handling stateful things like forms and form validation is a breeze, rather than writing components and endless abstractions. It's enough for the vast majority of the time.
Those are just shitty codebases. I maintain a React app that's over 10 years old, almost milion lines of code and we have zero components with 20 props, no issues with performance or whatnot.
I am an oponent of over-abstraction but components are very light abstraction and provide just sensible encapsulation and reusability.
I'm really curious too, the only codebase I've seen that was like their description with react treated different pages/routes as one massive separate component.
Not exactly utilizing the benefit of JSX but it's a pattern you might blindly fall into if you only came from a templating background.
I can't, our app is enterprise SaaS built as SPA. Nextjs is imho garbage. The only reason I can imagine it is so popular is that average React devs are indeed very bad with code organization. If I needed server rendering I would go with Astro + interactive islands.
I see, you're talking about a fully client-rendered SPA. I guess you can always count on your users running modern PCs, with fast internet and no SEO needs. Things aren't that nice in the outside world lol.
