Hacker News Reader

Comment by sktrdie | Hacker News Reader

One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the exact things that caused a screen to render. And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched (<with this data>) -> FrozenUser. One can rewind the actions and iterate with the stakeholders why that screen appeared. This is huge and I miss this a lot.

1. Note that most of the time the stakeholder is yourself and/or another developer. But can also definitely be a non-coder.

View on HN

It's worth noting that the Redux DevTools Extension _can_ capture and display a literal stack trace for every dispatched action, if you've enabled that while setting up your store. This allows you to see what part of your app triggered each state update:

https://github.com/zalmoxisus/redux-devtools-extension/blob/...

I always see you in these Redux threads and you are always so helpful, thank you!

The posted article is actually acemarke's

https://news.ycombinator.com/item?id=22822655

https://cerebraljs.com/

cerebraljs was superseded by https://overmindjs.org/ according to the docs: https://cerebraljs.com/docs/advanced/typescript.html

it's also not clear how this is a replay to the above...

I was about to ask what kind of stakeholder gives a damn about sitting down with you and going through an action trace to see why a certain screen rendered, but I’m glad you added the note at the bottom.

Regardless, yourself or another developer as the “stakeholder” in this scenario is a bit of a cop out. In the real world stakeholders aren’t technically inclined and even if they are they don’t care about this minutiae.

I was tempted to say something like ‘are you recently out of college or a bootcamp? What stakeholder are you impressing here with a Redux stack trace?’.

I tried to avoid it but your post just brought out it of me.

Please start thinking of "stakeholder" as everyone who has a stake in a project. This includes those who have to maintain the code and those who have to operate the service. Thinking this way will help ensure requirements gathering includes all stakeholders.

No, I keep a very mercenary mentality when it comes to projects. I’m told what needs to be done and I do it and get paid for it. Early on in my career I cared too much, and it brought nothing but unnecessary stress. I will never sit down and watch a redux stack trace, it’s not my job and I got better things to do.

Have you written about this experience transition? I'm interested in reading stuff like this

No, and I don’t imagine I’ll write much more about it than these few comments.

I think a lot of developers start off the same way. Idealistic, starry eyed recruits eager to put their knowledge to use and make a product better than they found it.

But then you realize life’s too short to bother with things like Redux. We’re not building software to last thousands of years, there’s no future archaeologists who are going to spelunk through our ancient code and be in awe at the ingenuity of our primitive minds.

We’re lucky if we’re writing software that lasts a couple quarters. Especially when you’re building front end UI, you can expect whatever you do to be completely bulldozed by whatever trend or framework comes along.

So don’t care. It’s not your job, you’ll be paid regardless. If someone wants me to care about a project, they need to pay me extra. Because caring forces that project to take up space in my mind and takes attention and focus from other things I actually want to care about, such as getting my work done and meeting objectives. Early on I used to care so much it would actually interfere with my ability to get things done in a timely manner.

And when co-workers turn around and shit on you for slowing them down, and you see they don’t care either and still get the same pay and recognition, or maybe even more in some cases, you realize there’s no point. That’s not how this business works. Don’t be a hero.

By now I’m so experienced with React I don’t need some time travel debugging tool to tell me shit, even with very complex state. I never have. If I run through an error a few times and throw some console logs I can quickly find and solve the problem 99% of the time. A valuable skill.

You are 100% right. It looks like people from this thread never ever left their own apartments and don't know anything about real projects.

Even better to combine this with sentry. So you can see all the actions that led to the error.

I use redux-sentry-middleware for that [1]

[1]: https://github.com/vidit-sh/redux-sentry-middleware

Any idea if bugsnag can do this too?

Overrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.

I found it incredibly useful when debugging race conditions, usually caused by network requests.

In the vast majority of React apps you do not need this.

I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's a lot of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps don't need to trace actions, but when you do you definitely won't think it's overrated.

> You're right that the majority of React apps don't need to trace actions, but when you do you definitely won't think it's overrated.

I think Redux is overrated because it is used by a lot of applications that don't need it.

Can you give me an example how you got to 400 actions? Just enumerate like 5 or so, I’m assuming you are building features where groups of actions are just necessary based on the patterns you are using.

I’m genuinely curious because I feel like this kind of inflation of actions/reducers in Redux is what makes it nightmarish.

For one thing they do encourage a lot of tiny actions. A frequent pattern I use requires three actions for every server call: one to trigger a saga, one when it succeeds, and one for when it fails.

The standard form is incredibly verbose, I've started to shift away from it.

Note that the new `createAsyncThunk` API in Redux Toolkit handles generating and dispatching the promise lifecycle actions for you [0]. Also, while sagas are a great power tool, most Redux apps don't need them [1].

[0] https://redux-toolkit.js.org/api/createAsyncThunk

[1] https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

Awesome! It's great to finally have some links to share.

The company I'm currently working with is the first time I've used sagas / observables / "anything async is through side effects". I've constantly been saying "this is madness, this giant block of code, all these concepts, all this room for things to go wrong, just to do a `fetch`?". It's also the first time in a few years of using redux I've had to deal with race conditions.

Edit: Oh, and you can even `await dispatch`! All the things I've been doing in Redux for years and told I shouldn't, now being officially endorsed.

Can you give me an example how you got to 400 actions?

I'm not going to go in to detail on HN, but the app I work on is used to make diagrams for the legal industry and to define how they change over time. It's sort of like Visio for lawyers, with a basic animation editor that understands the underlying data. There are a lot of actions simply because it does a lot of things that can't be generalised in to higher level actions (well, they could, but it'd be messy.)

Here's a real-world example, from an OpenStack dashboard developed in my team that uses React/Redux for some of the newer parts (most parts are still server-side only): https://github.com/sapcc/elektra/blob/e4d93bc601caa99cceb7ba...

That's 76 actions just for the NFS/CIFS-as-a-service UI.

(I'm not saying this is the best way to do it, but that's what's happening right now.)

400 actions is actually not that much at all... I would even say, quite a small app.

Ugh, we get it. Only 1 billion rows, it’s not big data yet ;)

I concur. I used React for a year or so I never used this feature once. I was too busy writing all the necessary boilerplate.

any application that you need to debug, I have not ran into a application React or not that I didn't need to debug and Redux does help with debugging greatly.

Have you used it? That’s like saying the Chrome debugger or CPU call stacks are overrated. It’s a debug feature that any React+Redux app can use to trace back why something happened. I’ve used it a few times, and when you need it because you don’t understand why an action was triggered, it’s super convenient.

You know what happened, not how. Was it a user click on this button or another button? Or was the action triggered by a saga?

Reply on news.ycombinator.com