5 ms·
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
by sktrdie 7y ago
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.
- acemarke 7y agoIt'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/master/docs/Features/Trace.md https://github.com/zalmoxisus/redux-devtools-extension/blob/...
- dprai 7y agohttps://cerebraljs.com/ https://cerebraljs.com/
- spex 7y agocerebraljs was superseded by https://overmindjs.org/ https://overmindjs.org/ according to the docs: https://cerebraljs.com/docs/advanced/typescript.html https://cerebraljs.com/docs/advanced/typescript.html it's also not clear how this is a replay to the above...
- petilon 7y agoOverrated. In what kind of application do you need this? In the vast majority of React apps you do not need this.
- sefrost 7y agoI found it incredibly useful when debugging race conditions, usually caused by network requests.
- onion2k 7y agoIn 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.
- petilon 7y ago> 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.
- runawaybottle 7y agoCan 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.
- jfengel 7y agoFor 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.
- xwdv 7y agoI 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.
- runawaybottle 7y agoI 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.
- brlewis 7y agoPlease 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.
- xwdv 7y agoNo, 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.
- thirtythree 7y agoHave you written about this experience transition? I'm interested in reading stuff like this
- xwdv 7y agoNo, 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.
- efrafa 7y agoEven better to combine this with sentry. So you can see all the actions that led to the error.
- longnguyen 7y agoI use redux-sentry-middleware for that [1] [1]: https://github.com/vidit-sh/redux-sentry-middleware https://github.com/vidit-sh/redux-sentry-middleware
- heyoni 7y agoAny idea if bugsnag can do this too?