React-redux-universal-hot-example: How can redux cope with large state?

[skywickenden]

First of all, thanks for this blueprint. I've learned a great deal from it. However I am a little confused about memory handling.

As I understand it, fetching data from a database is handled through api requests in redux action creators. The response is picked up in the reducer and appended to the state, which in turn triggers the relevant React modules to re-render with the new data.

I can see the advantages of this, but what happens when the data being fetched is frequent and large. EG a shopping site, where product descriptions are fetched. Or a wiki with all content is in the database. The state could quickly grow to multiple MB and as the sate is reproduced in its entirety with every action this could quickly balloon to unmanageable proportions, especially for mobiles.

Am I understanding this correctly? For example https://github.com/erikras/react-redux-universal-hot-example/issues/738 would be faced with this problem but it is not mentioned.

If memory could be an issue then we need a way to maintain a single reference to the data in state unless that data is changed. Resulting in a state tree that on the surface is unique for every action, but has underlying memory handling features that reference a single instance of the data for each change to that data.

I've never used immutable.js before, but it seems that it could do this. As far as I understand, Immutable.js would enable redux to maintain a unique state for each action, but behind the scenes each datum would be stored only once until it was modified.

Is there a reason that something like immutable is not being included as standard?

I came across https://github.com/erikras/react-redux-universal-hot-example/issues/152 which pointed out how to integrate immutable using https://github.com/indexiatech/redux-immutablejs, but it is out of date. The store is now created in /src/redux/create.js

I'm happy to have a go at doing this. But before I do, am I right or is the memory issue already handled and I am not seeing it?

Also, would a pull request be desired? redux-immutablejs would be integrated behind the scenes and reducers could still be written in the normal fashion, only using the redux-immutablejs format when immutablejs memory saving features are required.

[Whoaa512]

I'd love to see this implemented such that it could be toggled or used for specific slices of the state tree.

I'm not running into this problem yet though I definitely see the concern as an application grows in complexity. If a PR is not welcome in this repo, please feel free to send one to my fork of this starter. I'd love to collaborate on this and iron out the bugs.

[skywickenden]

@Whoaa512 Happy to collaborate, but I'm going to wait a little to see if @erikras or any of the others who have been involved have anything to say.

[erikras]

If you are displaying 2 MB of text on the screen, then you need 2 MB of state. The state javascript is garbage collected, so the old copies of the state are discarded. Yes, if your application is huge, duplicating your state on every action could get onerous, and Immutable JS with its ref sharing is a solution.

That being said, I think that a boilerplate such as this should be as unopinionated as possible and should stick to standard javascript objects rather than adding many dependencies that might not be right for all applications.

[skywickenden]

Thanks for commenting @erikras

On thinking about it, I can see that the history would only have one copy of each product description, because the property in the state for the product description would be overwritten every time it was updated.

[erikras]

I think you're over-worrying about performance. Report back when/if there is a problem.

[trueter]

The core idea is that _branches_ of nested data can be reused even though new objects are created. Lee Byron does a great job of explaining how immutable data structures and performance play well together here.

[skywickenden]

Yes, I realise that now. Thanks for the link, I'll watch it later.