Mark Erikson

I can definitely see the potential use cases for maintaining additional indices. That said, this is the first time anyone's asked for something like that. So, my off-the-cuff response is...

Mm... first question, I think, is about the actual state design and behavior. What form should these additional indices take? Objects? Arrays? Dealing with just the IDs, or the actual...

Adding extra args here won't work because those functions need to work as standalone reducers.

FWIW, I'm still open to this and any other ideas for improving `createEntityAdapter` - I just haven't seen any further discussion going on here.

Sorry, I'm not sure what API or behavior changes you're trying to show in that example. Can you clarify what you're describing?

Okay, but I don't understand what you're proposing in terms of a second "ID index" here. It would help if you could describe what you're expecting to have happen, preferably...

Not really sure how that helps. For one thing, the API adapter CRUD methods already have defined return values, so we can't change those. Second, the CRUD methods either "mutate"...

There _are_ times when maintaining an additional filtered list of IDs _might_ be useful. See https://medium.com/@dcousineau/advanced-redux-entity-normalization-f5f1fe2aefc5 .

We're not looking to implement a complete normalization solution of arbitrary incoming data. For that, there's https://github.com/paularmstrong/normalizr , and we have a usage guide section that suggests how to use...

Hmm. Okay, that's at least something concrete that I can look at, but I'm not following the intended behavior exactly. In particular, this "key" parameter that you're passing in seems...