v5 version

[turnerhayes]

Will there be a branch for redux-persist v5? Could this be accomplished by simply updating the dependency?

[rt2zz]

Its not clear yet how we will handle immutable integration with redux-persist v5. Open to suggestion, but we want to wait to add the necessary hooks until the v5 api is solidified.

[dominictracey]

It would be great if the various derivative products could be kept in step. e.g. I need this (my top level state is an immutable Map containing Maps for each of the reducers in the app), but I would also like the migrate capabilities as described in issue 28.

[jbiros91]

Any upadates?

[rt2zz]

Nothing yet, but I will say this:
a) redux-persist v4 works great for 95% of use cases, so no reason not to keep going with that.
b) redux-persist v5 can support immutable in a similar fashion to v4, its just a matter of doing the word to stub out the various getters/setters/iterators and provide tests.

[jbiros91]

I agree, I wanted manly that PersistGate component for React which is coming with v5, is it possible to to add that component to this repo?

[rt2zz]

No unfortunately that requires some fundamental changes (storing persistence state in.. state) and was a major motivation for v5 :)

redux-persist-transform-immutable will still work, just not top level immutable :/

[jbiros91]

I understand thank you for clarify things for me I will stick to v4 for now, I hope you will upgrade this repo to v5 soon... :)

[brunolemos]

+1 for proper immutable support on v5
I think this warning should be on redux-persist readme as I just realized it didn't support it after making all the migration

[AxoInsanit]

Would love to have v5 support as well, thanks for all the hard work

[chrisgbaker]

Has there been any more thought on this? I'd like to migrate to redux-persist 5.x.x but right now this is holding that work up. I saw in August 2017, the hesitation was in waiting for the redux-persist api to be solidified; is it in a good enough state to move forward?

[taranda]

It has been three months so I guess I'll bump this. Any thoughts on upgrading this to v5. I use Rematch with Immutable JS and rematch is only compatible with redux-persist v5.

[ezzatron]

It's worth noting that you can upgrade to redux-persist v5 today whilst still retaining individual reducers with Immutable JS state. I accomplished this by:

1. Ditching redux-immutable's combineReducers() in favor of regular old Redux combineReducers().
2. Ditching redux-persist-immutable, and just using redux-persist-transform-immutable directly, which already supports redux-persist v5.

From my perspective, there's really no downside to this approach. You need less dependencies, and you don't lose anything important. Ditching redux-immutable actually ends up being nicer since you can go back to using .foo instead of .get('foo') with any state produced by combineReducers().

I'd actually say @rt2zz could deprecate this library, and simply document how to move away from it, and that would solve this issue.

[taranda]

@ezzatron thanks for the advice. I will look into refactoring my project to no longer use an ImmutableJS object as the top-level store. However, for me and others, it may turn out that refactoring the store is not feasible. Also, it seems the authors at Redux.org recommend making the entire Redux state tree an ImmutableJS object. That is just one opinion, but it is a worthy opinion to consider.

For all of these reasons, I would strongly consider not deprecating this library, or at least forging a path to using redux-persist v5 with an ImmutableJS state.

[alecmev]

@taranda None of that doc is written by Dan, just in case 😛

[taranda]

@jeremejevs Fair enough. I'll edit my comment. :)

[StevenLangbroek]

@ezzatron unfortunately it's not that easy for us, and I imagine it's the same for others: we have a massive codebase, and because of ImmutableJS's nature, it has become pervasive in our project. Removing ImmutableJS, even just a top-level reducer, would mean updating selectors, components, reducers and so on, and will take significant effort (read: several months). In the meantime I'm introducing persistence, and would love to use redux-persist, but am hampered by this shortcoming.

[taranda]

What if we added a config to redux-persist's combine-reducers method allowing the user to pass a custom combine-reducers function?

[turnerhayes]

@taranda As I understand it, the problem isn't with combining reducers so much as with persistReducer() returning a reducer that assumes the state is a plain object (and coerces to such) before passing it to the reducer it wraps.

I have a workaround that seems to work, although it's probably not optimal (haven't tested performance or anything):

import { Map, is } from "immutable";
import { persistReducer } from "redux-persist";
import immutableTransform from "redux-persist-transform-immutable";
import { combineReducers } from "redux";
import { connectRouter } from "connected-react-router/immutable";
import localForage from "localforage";
import createHistory from "history/createBrowserHistory";

const persistConfig = {
	key: "my-key",
	storage: localForage,
	transforms: [
		immutableTransform(),
	],
};

export default function createReducer({
	injectedReducers,
	history = createHistory(),
} = {}) {
	const reducer = persistReducer(
		persistConfig,
		combineReducers({
			<reducers>,
			...injectedReducers,
		})
	);

	return connectRouter(history)(
		(state, action) => {
			const objState = state ? state.toObject() : {};

			const modifiedState = Map(reducer(objState, action));

			if (!is(modifiedState, state)) {
				return modifiedState;
			}

			return state;
		}
	);
}

The idea behind the is() check is that, if the state hasn't actually changed as a result of the reducer, then we don't want to return a different object. I'm not sure if that's practically necessary, but referential integrity is one of the advantages to using Immutable, so I'm going with it for now. Could potentially be a performance bottleneck with large state trees.

EDIT: the above doesn't actually work; it still makes some things objects.

That being said, it would definitely be good to have actual support for Immutable; it would probably require parameterizing a bunch of things like getting/setting/merging.

[OneStromberg]

I did something on the weekends;
This version just for working;
As said @turnerhayes problem was in persistReducer that returned plain object instead of Immutable.
Lets find bugs and improve, so everyone can use it.

[jgadelange]

@OneStromberg I'm using your version, seems to work pretty decent.
However I'm having some trouble persisting an Immutable List (converts it to an array when coming back)

Any plans on creating a PR of your work? Otherwise, any good way to add issues to your repository?

[OneStromberg]

@jgadelange PR is made, this project looks abandoned, so my PR is not moving.
Let's find the way how you can explain to me a problem, and try to fix that.

[jgadelange]

Ah I see. Maybe enable issues in your fork? I think discussing the problem I'm having in this issue is not the best place. So I will describe it here and if we have another place where I can move it I will do that ;)

Problem description moved to: helloheartteam#4