An equally good argument to normalize or flatten nested data is when it comes to updating this data. This is well explained here. Because this is a common use-case, Dan Abramov created normalizr, later re-written and now maintained by Paul Armstrong.
But if you also control the API, and you probably store the data in normalized form in the database, it's rather silly to de-normalize it in your API endpoint only to normalize it straight after in your client (using normalizr)... In that case, certainly if you're the only consumer, just leave the data normalized and pass it over the wire to your client like that.
Concretely you'd have something like this
GET /meetings
{
"result": ["1", "2"],
"entities": {
"meetings": {
"1": { "id": 1, "date": "2016-01-01", "attendees": [1, 2, 3] },
"2": { "id": 2, "date": "2016-01-02", "attendees": [2, 3, 4] }
},
"users": {
"1": { "id": 1, "name": "User 1" },
"2": { "id": 12, "name": "User 2" },
"3": { "id": 13, "name": "User 3" },
"4": { "id": 14, "name": "User 4" }
}
}
}
Such response is very straightforward to merge into your store in a generic way.
If you have multiple consumers, you might opt for a normalize=true query parameter. You might also want to combine this with some kind of expand|include=entities,to,include query parameter.
Finally, note that the JSON API spec doesn't play nicely with the normalized structure of flux/redux stores.
Further reading: