See callstack for events.

[joshsten]

A problem is finding the source of events in the event list. It'd be nice to have an option to click an event and view the callstack that triggered the event.

[oleggromov]

It would be really useful, especially since debugging in redux sometimes becomes unfairly tricky.

[markerikson]

This is a great idea! Don't have time to try adding this myself, but it'd be a fantastic addition.

[mpeyper]

Came here to create the same issue.

@markerikson proposed a middleware for doing this, but I think it would be incredibly useful as part of the dev tools extension.

[markerikson]

The DevTools implementation would need to capture the stack trace for later use, not just log it to the console, but yes - this would be a HUGE benefit.

[mpeyper]

I believe something like new Error().stack will capture the current stack trace... not sure if it's a good idea though:

Different browsers set this value at different times. For example, Firefox sets it when creating an Error object, while PhantomJS sets it only when throwing the Error, and MSDN docs also seem to match the PhantomJS implementation.

[theKashey]

Generating stack traces is a pain. Thank's god we have got stacktrace.js!

[markerikson]

Hiya, folks. I got it in my head this evening to see if I could make this happen... and I did! It took a small addition to the redux-devtools-instrument package to capture an error and serialize it, and then the remotedev-app package (which has the actual UI used by the DevToolsExtension) had to be updated to add a new tab to display the stack frames.

The frames are being displayed completely unformatted right now, but once the basic display is added, we can do a lot more work to format them better, such as clickable frame entries that jump straight to the right source in the debugger. That part I have no experience with, so hopefully someone else who has done extension development can figure that part out.

Also, at the moment I'm only doing new Error() to get the initial stack trace data. It's very possible that's not sufficient cross-browser, per the comments in the Stacktrace.js readme: https://github.com/stacktracejs/stacktrace.js/ .

Perhaps we might also want to add an option to not capture the stack traces, just in case someone is worried about performance or something.

I would think that once both these pull requests have been merged to those packages, it should just be a matter of rebuilding and republishing the DevTools Extension package to get the results.

Here's an example of what it looks like in action:

[markerikson]

A couple quick thoughts on filtering stack traces. I'm currently using stacktrace-js to parse the serialized Error and turn it into an array of stack frame objects (including using sourcemaps to clean up the files and paths). Searching around, there's a lib called https://github.com/xpl/stacktracey that looks like it can do some of the same things, but also filter the results based on certain libs.

There's also the code in the react-error-overlay package used by CRA to parse errors, too. That code in particular is really interesting, because it not only cleans up source lines and uses sourcemaps, it actually highlights the line where the error occurred WITH the original source if available, like this:

It'd be cool if we used that approach to highlight where the action was dispatched. I imagine it would take some heuristics, though, because otherwise a lot of it might be just the internals of bindActionCreators().

[theKashey]

Is it possible to trace "async" events, like button->click->event->saga->event->saga->event....? Like how one event could create another, to find the roots

[markerikson]

@theKashey : that one I'm not sure about. I know that the actual browser debuggers can link together things like that, but I have no idea how that's implemented.

[markerikson]

Today I was able to use the stack trace parsing logic and display UI from react-error-overlay, and cram it into the "Stack" tab in the DevTools Extension. A couple examples:

A click handler from my "Project Mini-Mek" sample app:

An action from the new Reddit UI:

I've pushed the changes to the remotedev-app PR linked earlier in the issue.

At this point, there's a couple major issues:

• The PR code is pretty hacked-up and required Babel config changes to build okay
• @zalmoxisus hasn't been very active lately

So, I'm not sure when we might actually manage to get this merged in and an updated version of the DevTools released.

[mpeyper]

If you want to make a PR, I'm happy to help with code review to help get the code cleaned up. Can't help with maintainer activity.

[markerikson]

PRs are already open and linked above, but I'll re-link them here:

zalmoxisus/redux-devtools-instrument#21
zalmoxisus/remotedev-app#43

The remotedev-app one has almost all the changes, and thus the one that needs cleaning up.

[markerikson]

Since I'm not sure when this will be merged in, I'm going to attach unofficial builds of the extension for Chrome and Firefox.

Chrome

1. Download Redux DevTools Extension with action stack traces - Chrome.zip
2. Double-click to extract
3. Visit chrome://extensions
4. Ensure "Developer Mode" is enabled
5. Click "LOAD UNPACKED"
6. Select extension

Firefox

1. Download Redux DevTools Extension with action stack traces - Firefox.zip
2. Visit about:debugging
3. Click "Load Temporary Add-on"
4. Select extension

It definitely looks like clicking on a stack trace entry will not open the debugger in Firefox, because the chrome.devtools.panels.openResource() API is not available in Firefox, and I don't know what its equivalent is (if any). But, seeing the file name and potentially the lines should be an improvement, and you can always manually open that file yourself.

[digitarald]

the chrome.devtools.panels.openResource() API is not available in Firefox

Filed as bug 1503475.

[zalmoxisus]

@markerikson did a great job working on this, but, as mentioned, it's still first step and there're some parts to finalize before moving to production, as discussed in zalmoxisus/remotedev-app#43. Also it was implemented against master branch which is old and everything is rewritten in another branch, so I'll have to reimplement it there. I'll finish with critical issues and come back to this one, if someone wants to help, I can assist with more details on what should be done.

Meanwhile can install the package kindly provided by Mark in #429 (comment). Or for only seeing callstack (withoutreact-error-overlay ui part and jumping to the source), can just add stack: window && window.__REDUX_DEVTOOLS_EXTENSION__ ? Error().stack : undefined in the root reducer. That's exactly what we're sending to the extension.

As discussed in zalmoxisus/redux-devtools-instrument#21, for this feature we'll add shouldIncludeCallstack parameter. If someone can benchmark const stack = Error().stack in different scenarios and it doesn't have significant performance impact to consider as a regression, we can enable it by default. I suspect it would depend on many factors.

[zalmoxisus]

I did some tweaks in reduxjs/redux-devtools#418 and it's almost ready. Have to finish some other work, and should have 2.17 published next week. If you want to give it a try, here's the archive you can unzip and load in Chrome/Firefox according to the instructions: extension.zip

A sneak peek:

Apart from opening resource, as seen in the demo, it can open the file (and jump to the line-column) right in your editor. Pretty useful for debugging, and also as an alternative when there's not possible to use openResource (for Firefox or when using the extension from window or for remote debugging). When there's no openResource support, It'll suggest to specify your editor on Options Page, but you can click Settings button and enable that, also adding the path to your project root directory to append the paths to it. It works out of the box for VSCode, Atom, Webstorm/Phpstorm/IntelliJ, Sublime, Emacs, MacVim, Textmate on Mac and Windows. For Linux you can use atom-url-handler.

By default the extension won't get stack traces, to not affect the performance, have to set trace option to true as in examples. I'll update the docs, but for more details see instrumentation API.

For some edge cases where stack trace cannot be gotten with just Error().stack, you can pass a function to trace with your implementation (for example when don't want to lose stack trace before calling setTimeout). It takes action object as argument and should return stack string. This way it can be also used to provide stack conditionally only for certain actions.

There's also an optional traceLimit parameter, which is 10 by default, to prevent consuming too much memory and serializing large stacks. It's useful for Firefox, as for Chrome call stack is limited to 10 anyway. However, even for Chrome it could be needed to get a larger stack than with 10 frames.

[zalmoxisus]

It's now available in 2.17. Here're more details: docs/Features/Trace.md.

[zalmoxisus]

Closing this. Refer to redux-devtools-trace-monitor package for issues and pull requests. When chrome.devtools.panels.openResource will become available on Firefox it should work with the extension without any changes from our side. For now, opening in an external editor is a nice workaround. Thanks to everybody here for helping with this!