Normalizing State Shape

[StevenXL]

Hi Folks,

I want to update the Normalizing State Shape docs.

I'm 100% on-board normalized state shape, and its benefits. However, while the docs allude to using the principles of database design whenever possible, it seems like the current docs go against this idea.

What I mean is that we have a relationship in the docs where a Post has many Comments. We model this relationship by having a Post object contain a comments key, which is an array of comment ids. If we were to follow database design principles, shouldn't the comment have a postId property indicating which post it belongs to? In other words, shouldn't the "foreign key" be on the comment, rather than on the post?

I'd like to propose two changes to the docs:

1. Change the docs so that the "foreign key" is on the Comment, not on the Post.
2. Change the docs so that we don't keep a list of allIds, since it seems to me that this is data that can be calculated, and therefore shouldn't be stored.

I haven't made a PR of these changes because I am not sure if I am missing something, but if a project maintainer thinks these changes would be improvements, I'd be happy to make a PR on it.

[timdorr]

Please make a PR. Issues aren't good for discussing specific docs changes.

[markerikson]

I can point to two discussions that help answer this question.

First, someone (you?) asked this over on Reddit today, and one of the comments had a good explanation for the location of the keys:

I think your looking at it a bit too much like a database rather than the hierarchical json structure that it is. It's faster to read from a hashmap than it is to search through a multi-level json object, like it's faster to get comments[ID] rather than doing a comments.filter(x.id==id) especially if you have tons of objects..

To expand on that a bit: in this example you would probably have a <Post postId={123} /> component rendering the post's content. By keeping an array of comment IDs as a field inside the post entry, the <Post> component can map over those IDs to render the <Comment> child components, which can be done as direct lookups. Otherwise, you'd have to do a complete scan of the comments "table" to find all comments whose postId matches the post.

You're right that the allIds array isn't completely necessary, but it's useful. There was a recent post called Redux Patterns: Rethinking byId and byHash structures that made the same argument. I left a few comments on that that relate to this question.

[StevenXL]

@markerikson I saw that thread on reddit and the idea sounded good, so I posted here. Thank you for the response.