Redux-persist: Is it possible to create an async transform?
Looking through the listed transforms I've noticed redux-persist-transform-encrypt has an async version but it appears to simply wrap the sync one and the README has the following note:
Asynchronous support is still a work in progress.
Any plans on supporting async (Promise-based) transforms in the (near) future?
cascornelissen
All 12 comments
@rt2zz, I would love an answer on this as I will have to write my own storage solution or submit a PR if this isn't supported in redux-persist. Thanks in advance!
cascornelissen
on 23 Mar 2017
@cascornelissen sorry for the delay. Currently async transforms are not supported. I am open to the idea but we would need to be very careful around performance and also error handling.
What is the specific need that is async? Is it possible you can bake the async portion into the storage engine (which is already async, namely getItem and setItem)
rt2zz
on 2 Apr 2017
@rt2zz, I'm trying to transform data via SubtleCrypto before storing it.
I started working on something but haven't had the time to dive into it any deeper. You might want to give me some pointers/tips though, I've only implemented a working inbound transform so far: https://github.com/rt2zz/redux-persist/compare/master...cascornelissen:master
cascornelissen
on 3 Apr 2017
nice, approach seems reasonable. I am still not sure how this feature fits in, given that this complicates the common case. I am working on some lower level refactor atm, so for the time being I think the best options are either
- keep rolling with your fork
- implement the async encrpytion in the storage engine
rt2zz
on 4 Apr 2017
Given the fact that I want to use multiple storage engines based on the environment later on I'll go with option 1 for now. Could you let me know when this refactor is finished (and do you have any ETA)? I might want to submit a PR at that time to implement the Promise-based transforms if anyone's interested.
For the argument saying that it complicates the common case: I agree, maybe we could make this configurable behind a flag? But we'll see once your refactor is finished.
cascornelissen
on 4 Apr 2017
@cascornelissen I actually need the same thing; did you keep rolling with your fork (and is it published anywhere?)
CharlieHess
on 27 May 2017
@rt2zz I went ahead and implemented it in https://github.com/rt2zz/redux-persist/pull/360. I have a pretty well-defined use case (a reducer that is used very infrequently, but needs to imbue state with passwords from https://github.com/atom/node-keytar) and in my testing there is no perf impact.
CharlieHess
on 29 May 2017
@CharlieHess, unfortunately not, some more important work came in but I love what you've been working on so far!
cascornelissen
on 29 May 2017
@CharlieHess I was going to mark this issue stale since the issue hasn't been updated in a long time, but it looks like your PR is still outstanding and you're still seeking feedback now that v5 is out.
Discussion in here: https://github.com/rt2zz/redux-persist/pull/360
Is this still something you'd like a resolution on? Thanks for submitting your PR to the project. @rt2zz seemed somewhat concerned about the support burden of this PR, and he's already stretched in supporting this project. It would help the project immensely if we could get a commitment that you'd help support this feature and address any issues that come up with it.
aguynamedben
on 22 Dec 2018
Tagging a few of the other people who seem interested in this feature from PR comments: @antondomratchev, @cascornelissen, @jstaab, @mnquintana, @sebastian-schlecht
aguynamedben
on 22 Dec 2018
@dahannes, @dhruvparmar372, and @mairi17 also seems interested in the PR based on 馃憤's. My project also stores things in keytar (async) that I wish would be blacklisted and rehydrated. So there seems to be around 9-10 people wanting this, including people who work at Slack and legit companies.
That is @CharlieHess stated use case:
In my case I wanted to store secrets securely (say, in the keychain) and have them excluded from the persisted shape. Then, on rehydrate, I wanted to read the secrets from the keychain and apply them to the state as if they were there all along.
aguynamedben
on 22 Dec 2018
@aguynamedben sooo, at slack we've pretty much stuck with my fork for the time being, but eventually we'll have to upgrade from v4 => v5 and then I'll come back to this. I can't see that happening in the near-term though. 馃様
CharlieHess
on 18 Feb 2019
Related issues
therise3107
路
3Comments
thenewt15
路
3Comments
antoniomelendez
路
3Comments
openscript
路
4Comments
Clumsy-Coder
路
3Comments
Most helpful comment
@rt2zz I went ahead and implemented it in https://github.com/rt2zz/redux-persist/pull/360. I have a pretty well-defined use case (a reducer that is used very infrequently, but needs to imbue state with passwords from https://github.com/atom/node-keytar) and in my testing there is no perf impact.