This is a general debugability problem that all runtimes have-you now need an understanding of how React’s implementation works to map the runtime’s state to what you’re attempting to do.
I very rarely run into a case where that occurs, and almost never that doesn't involve ignoring one of the ESLint warnings that CRA sets up in its default settings.
Now, getting the stack trace to only point you to some part of a component library's code seems more common.
Usually it’s always the same error anyways. Something is undefined or typed wrong.
This highlights one of the biggest issues with React: usually it works really well, but if you're unlucky enough that it doesn't then there's almost no way to work out why. I've been developing with React for about 4 years and I just don't upgrade things in the ecosystem unless I absolutely have to, because debugging the tooling is a massive pain.
This is also why it's very unhelpful to say that it works. Yes, it usually does, but not always and failing to understand that comes across as somewhat antagonistic.
But then the churn in the interdependent platform and packages means your project is moving towards a state that it cannot be upgraded without significant risk and rewriting around the deprecated packages.
In my opinion this is a major issue with React in the landscape of businesses that have a halflife of more than a few years.. ie most long term businesses.
Yet despite the long term fragility and maintenance issues it's a topic that is missing in most discussions about React. The React conversations tend to be 'how can we keep up with the latest churn' instead of recognising the churn itself is a problem and stability provides realworld business value in the medium and long term.
The stack traces are truly and utterly useless. One cannot see what triggered a rerender or other reactive action.
And a rerender can be triggered between two lines of synhronous code, magically, thanks to es6 proxies. What have I done???
To your point about best practices React, at least at the beginning was not supposed to be the entire stack, by design you needed other libraries to deal with large portions of the web state and as such it could only control a small part of your stack.
That being said with hooks and providers, it is gaining enough internal tooling to be almost “the whole stack” but still the philosophy remains.