createEntityAdapter with dynamic or fulfilled-order sortComparer

[ghost]

Can you give some guidance on how to do a dynamic sortComparer, e.g. ngrx/platform#898
or if you would even want to do that?

The sortComparer defines the sort order for storage, so I'm not sure that having a dynamic sort for that purpose is a good idea. The first answer on the linked ngrx issue recommends just using a selector to sort, which is probably what I'd do instead of constantly changing the storage sort order.

However, for the default order - I'd prefer it to be fulfilled-order (insert-order). Since you make no guarantees about the default ordering when no sortComparer is provided - how can I provide a sortComparer that always sorts the entities based on the order that they were fetched / fulfilled / inserted into the Entity Adapter?

[ghost]

I can see in the source code for the unsorted adapter that insert-order is the default sort order.

Would you consider documenting that and guaranteeing that it won't change without a breaking change version?

[markerikson]

Can you give an example of what you mean by "dynamic sortComparer"?

My main thought here is that the built-in sorting behavior is primarily a convenience factor. If you want something more complex or detailed, you should probably be managing your own sorting logic, in either reducers or selectors.

There's a bit of a parallel with the techniques shown in the post Advanced Redux Entity Normalization, which talks about having multiple "keywindows", which are really just additional ID arrays with some specific subset of IDs in them.

[ghost]

I'm trying to figure out exactly in what capacity should sortComparer be used.

So, I was wondering if it was intended as a way to sort things on behalf of the user. I imagined that a "dynamic sortComparer" would be one that changes what we're sorting by after some action occurs. When I looked at the nrgx issues I saw people asking about it there as well.

I don't think this is the true intention. I can see now that sortComparer is there simply to enforce a single, unchanging default sort order.

However, then I read the part about there being no guarantee of sort order if you don't supply a sortComparer. This could be a problem for me since most of the time (for me), sorting is done on the server. I would need the fetched-order to be the default. However, if you're not guaranteeing that order, I need to figure out how to preserve it myself and I don't see a way to preserve fetched-order by supplying my own sortComparer unless I add a new property to each fetched entity to retain the order it was retrieved, and then sort on that.

That seems like a lot of work to do when the default sort order of the unsorted entity adapter really is just insert-order (which would be the same as fetched-order for many of my use cases).

So, the issue here really just ends up being a question of documentation - why not guarantee the default sort order of the "unsorted" entity adapter so that it's always by order of insertion?

(Thanks for the link to the keywindows, I've certainly used that technique before. But when we're sorting on the server already - any additional work to re-sort things on the client would be undesirable.)

[msutkowski]

@waynebloss Hey Wayne! In the usage guide documentation, we currently say:

createEntityAdapter provides a sortComparer argument that you can leverage to sort the collection of ids in state. This can be very useful for when you want to guarantee a sort order and your data doesn't come presorted.

To me, this implies that you get what you give (or an array behaves like an array?) if you don't specify a sortComparer. I think mentioning something like "we use insertion order to guarantee the order you gave us" specifically could be more confusing as it implies that we're doing something special behind the scenes. As an example, there is no reference to insertion order in the MDN docs for an array, as that's the known behavior.

If this isn't clear enough, let me know and I'd be happy to open a PR with some ideas that bring more clarity to the docs.

[ghost]

@msutkowski This is the confusing sentence, the last sentence in this section of the API reference:

If not provided, the state.ids array will not be sorted, and no guarantees are made about the ordering.

Reading that was confusing to me because there was no positive statement about what the default sort order actually is. Instead, you have to infer it from a completely different documentation - the usage guide that you pointed out here

[ghost]

I'll just go ahead and close this issue because it started out as me asking about the intended usage of the sortComparer and I can see the answer to that now.

You can do whatever you want with your docs - I'm just trying to help you out by pointing out some confusion that I had. I'm sure most people will figure out the same thing on their own.

I guess my problem was that I jumped straight to the API reference for these new features instead of re-reading the usage guide.