Hacker News Reader

Comment by mikeryan | Hacker News Reader

Something is off with your transpiling set up if you’re not getting accurate stack traces. A “create react app” default setup will should have accurate stack traces out of the box.

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.

View on HN

What GP means is that the stack traces will often just point you to React’s runtime code.

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.

> What GP means is that the stack traces will often just point you to React’s runtime code.

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.

I run into this daily. There isn’t a single JS error in our monitoring that has a useful stack trace. It would have to extend another 30 layers down to start going into actual application components or code. They all look the same going through different bits of React internals.

I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable.

Usually it’s always the same error anyways. Something is undefined or typed wrong.

I click on my errors and they take me to the exact line of code that caused them.... basically the JS error throws the line number and file path and then my terminal setup makes it clickable.

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.

I completely understand what you mean about not upgrading things in the working ecosystem, it's the pragmatic choice in the short term.

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.

That’s sourcemaps. For simple errors like you mentioned it might be enough, but your stack is still useless for more complex issues. Usually it’s dominated by hooks / batch rendering code.

I’m wondering if part of the problem is that I’ve made a poor life choice in making this library the central state manager in a large app: https://github.com/RisingStack/react-easy-state

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???

Everybody makes state management hard.

All you need is a simple layer to make your typed api calls.

export const ApiService = {

  return {
    getSomeStuff: async () => ...,
    postSomething: ...,
    etc,
  };
}

Reply on news.ycombinator.com