Codecov Report

Merging#95 intomaster willnot change coverage.
The diff coverage is100%.

@@          Coverage Diff          @@##           master    #95   +/-   ##=====================================  Coverage     100%   100%           =====================================  Files           1      1             Lines          26     58   +32       Branches       10     13    +3     =====================================+ Hits           26     58   +32

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update0ab4e52...e101118. Read thecomment docs.

I've updated this PR with the 200kB check, so that we skip the initial request and just send the error without any state. But I decided it would be a good idea to still hande the 413 error and retry the request, because it was only a few extra lines of code.

Unfortunately there was no way to access thejson-stringify-safe code thatraven-js is using, because they include a vendored copy with some changes in the repo. I also couldn't find any way to intercept the stringified data before it was sent. So I ended up copying that same file intoraven-for-redux. It's only 76 lines of code, so not too important. (And felt a lot better than overridingfetch(),XMLHttpRequest, andXDomainRequest.)

Unfortunately, zlib compression withpako was a dead end. But I finishedsome proof-of-concept code to test it out.

It was actually very easy to get the code working, and the only issue is that Sentry refuses theContent-Encoding header during the CORS preflight request.

They probably just don't support gzip/deflate for browser requests. But it's a bit weird, because most of their backend API clients seem to send error reports with gzip compression. And also, I don't think this will even solve the underlying issue. Even after decompressing the data, they will probably still check to make sure it's under 200KB.I've also posted about this on the Sentry forums.

In the end, I've just removed thepast andfuture keys added byredux-undo (as a stateTransformer in my own code), and now my state is always under 200KB (including breadcrumbs.) I was thinking about sending the history to my own server and storing it in my own database, but I realized that it's not actually that useful. I usually only need the latest state, action, and breadcrumbs to see why something crashed.

This might be controversial, but I think it would be great if the default stateTransformer did a quick check for anyredux-undo history and automatically removed it, because that was the main source of my problem. Thepast andpresent arrays include full copies of the state whenever a user makes a change. It's not a problem in the browser because they share the same memory references, but it's a huge problem when you need to serialize that data. This library is already specific toredux, andredux-undo is the most common way of adding undo/redo functionality to a React/Redux application. So maybe this makes sense as a good default. Otherwise mostredux-undo users will end up with 413 responses, or no state at all (when using the code in this PR.)

I might send another PR for this idea, as a proof of concept.

Opened the PR to remove redux-undo history:#96

Even if you decide not to merge this, hopefully some people can find this and useremoveReduxUndoHistoryFromState as theirstateTransformer. Or maybe it would be a good addition to the README / Wiki.

+1 when is this planned to be merged?