search

mschipperheyn / normalizr-immutable

Other
123 stars 13 forks source link

Compatibility with transit-immutable-js #17

Open SvenC81 opened 8 years ago

SvenC81 commented 8 years ago

In my project I persist the state using redux-persist-transform-immutable (which uses transit-immutable-js) making it possible to store & restore Records to and from local storage. This works well for most of my state except the entities. The problem is that when using normalizr-immutable the entities are Records containing a list of Records, which is stored/restored by redux-persist as a Map because the persistor doesn't know the structure of the entities Records. This is how the entities reducer is persisted: image You can see the structure a bit: iR identifies a Record, iM identified a Map: entities is a Record (I defined it like that in the persistor), but users is a Map containing UserRecords.

Before persisting it looks like this: image

So after a restore, I can't access my objects anymore using number IDs so I have to convert my IDs to Strings.

I hope I'm making a bit of sense?

Do you see a way around this or should I just resort to referencing entities using a Map?

mschipperheyn commented 7 years ago

Ok, one question. Which version of normalizr-immutable do you use. I have made significant changes in the betas which I haven't deployed as a full version yet because not all of the tests are passing yet (but it works for me in production, so...yeah)

Ok.I need to have more info to respond. I tried redux-persist in the past but I haven't looked at it in a while. It would help if I could see your schemas.

So, one thing that I would consider as "expected" is that entity ids/keys in the entities structures are stored as strings. You should simply assume that so as not to create confusion later.

Another thing is the use of Proxies. Do you use them to access the objects in the entity structure?

Lastly, one thing I changed in the beta is that the entities structure is now stored as a Map always. Not doing so was basically a mistake on my part since we cannot always guarantee that all object keys (e.g. users, posts, comments) are always there on any given normalization. So, if one key is missing and we base a Record entity structure on the result, adding that key later, will fail. So, it's always a Map now, which means ids/keys get converted to strings. If you use Proxies for the result, you won't notice this difference too much in your code.

Should you use Proxies, you will need to implement a merger function that prevents immutable from parsing into proxy references when doing a deepmerge. I documented this on the beta README.

HTH