Expand docs to include complex models and memory usage

[brian428]

I'm not sure if this is the best place to make this request, but I don't see a forum or Google group, and since there's no way to add an issue to the "Comprehensive Introduction" Gist, I'm adding it here.

I'm already quite familiar with Angular 2, and have a decent grasp of RxJS. ngrx store seems like a very interesting idea, but I have two questions/concerns that don't seem to be addressed anywhere: ongoing memory use, and handling state that contains complex objects and/or class instances. My request would be to modify the docs/Gist to include some information on these two topics, because these were the first two concerns that immediately came to mind while researching ngrx store.

On memory use, it seems like the ngrx store actually "holds onto" all previous state. Is this is correct? My concern is that large amounts of state data would cause memory use to explode, especially if entirely new data (all new object refs) are loaded into the store. If the store actually maintains references to all previous state, this would obviously become a problem. But I'm not sure if my assumption is correct (that previous state does indeed linger in the store). And if so, I'm not sure if there's a way to have the store "garbage collect" outdated state (either automatically or manually).

My second question is regarding more complex state data. Most of the examples (and the docs) focus on very simple state, with objects containing a simple, flat set of properties. But what happens if the state contains complex/nested object graphs (e.g. users[0].roles[0].permissions[0].name?)

• Object.assign() only performs a shallow shallow copy/clone. Does this violate the idea of immutable state? And if so, how is this dealt with? Is something like the lodash cloneDeep() function used for this?
• What about rich domain models, meaning class instances that contain methods in addition to data? Are there approaches for using these in ngrx store? Or must the object state data be "extracted" from the class instance in order for the store to be able to deal with it (and re-applied to class instances when retrieved from the store)? And if so, is there anything built into ngrx store to handle this?
• If a state change actually applies to a nested object, how is that handled? Can complex/nested objects be maintained by the store? Or is the expectation that nested objects must all be stored as separate "slices" of state and re-combined if necessary?

In summary, the Comprehensive Introduction does a good job of explaining how ngrx store works when dealing with fairly simple state data. What I'm not clear on is what happens when the state data gets more complex. I think it would be worth talking about this in the docs somewhere, because I think that many people will have similar questions.

[kylecordes]

The most knowledgeable Store folks will no doubt have a more comprehensive answer. That I can help a little bit:

I believe the core Store does not hold on to past states. The development tools do (so that they can show you the path states etc.) but there is no reason to do so in the core, and at least when the question came up for me sometime ago I believe I found past states are discarded and can be garbage collected.

Which you are getting to on the shallow and deep copying stuff is immutability versus mutability. Unfortunately this is a problem across a wide variety of these tools. Store obviously encourages a generally functional way of thinking about application state. But how can you be functional when there is nothing pure on any of the underlying data structures? So far most of the substantial Store base code we have been using here, simply does a lot of deep copying. It is surprisingly fast, and only if you have large complex states the copy will it start to have a problematic drag on application performance, in which case you can switch to an immutable data structure library... but at the cost of more code at the point of using the data structures.

[meenie]

What I've been seeing a lot of is Store data structure emulates that of a relational database rather than a document store. So the data that goes into your store is normalised. So far, I've seen that work pretty well. Using higher level selectors to merge together different parts of your store. I agree there should be a bit more documentation on how to achieve that. There is an example app which shows how to do this as well.

[mjolk]

i'm using https://github.com/paularmstrong/normalizr but it makes getting stuff out of the store again a little trickier imo

[alanjhonnes]

I'm also using normalizr and trying to keep my entities relations completely flat as they are stored in the store.

For retrieving related entities out of the store, I'm using a service/pipe which access the store and retrieves the corresponding entity by id.

You should probably take a look at this course by redux's creator, which explains normalizr usage and how to deal with those things.

[ayyash]

It's disappointing to see this ticket closed without a clear answer regarding memory use

[littleStudent]

what part is not answered?
As @kylecordes explained, the store itself does not keep hold of state history. It only holds the current state. So memory usage is in line with the size of the store.

[ayyash]

I've seen that, but he said "I believe the core Store does not hold on to past states." which made me wonder, is it really so or not?

[fxck]

#372 (comment)

[mrpmorris]

The original poster doesn't mean that the store holds on to all iterations of state, but that any data ever loaded into state is kept there. There is no garbage collection, it is like having a static variable to a list of objects that never gets cleared down because you don't know when it is safe to clear it.