Ordered entities

[jamakase]

In some cases, it could be useful to store and display data in timed order. Like messages in the chat.

I tried to implement the receiving of new messages via custom redux action, but we know only ids of entities in updaters, so it is not possible to identify where to store entity.

export const conversationUpdated = (conversationUpdate: ConversationByOperator) => ({
  type: RECEIVE_MUTATE_TYPE,
  payload: conversationUpdate,
  meta: {
    schema: ConversationByOperatorResource.asSchema(),
    updaters: {
      [ConversationByOperatorResource.listShape().getFetchKey({})]: (
        newConvId: string,
        prevResults: { conversations: string[] | undefined },
      ) => ({
        conversations: [...(prevResults?.conversations ?? []), newConvId],
      }),
    },
    date: new Date(),
    expiresAt: 189231293812939889,
  },
});

Do you know how this can be done except manually sorting everything in react components?

[ntucker]

Thanks for the report!

Let me see if I understand your scenario correctly: Is there a member of the conversation that has it's date, that you want to use to determine ordering rather than the order in which it was processed? If this is the case, then you want to do a sort of 'insertion' event where you look for the spot to place it in a sorted list, correct?

[jamakase]

@ntucker Exactly! For example, we need to display a list of messages within conversation and receive new message via websocket. But it is possible for some case to get an older message first and then get a new one. If you just append ( or prepend ) ordering could be wrong.

I will be glad to help you with this feature if you do not have time if you give me some guidance.

[ntucker]

Ah interesting, ya we did start seeing use cases like this. We'll probably need to make some sort of backwards incompatible change to support this - though we're in 5.0 beta development now so that's not a huge deal.

I guess the most obvious thing to do would be to actually pass in what the denormalized response would be (something resembling what is returned from useResource or useCache) and then you return a new denormalized response as well. Then the return value would be normalized again to just grab the results to update. This would technically be a bit more computation, which is why I didn't initially do it, but I think it is less confusing and allows cases like this, so probably makes sense. Computation on a write like this is probably fine considering there will likely be more responses updating as a result.

One open question would be what if people alter the entity themeslves in the updater function? Should this be allowed? It probably has to. I guess that is fine?

[ntucker]

Now that I think a little more, this works well with my plans to create a universal memoization of denormalized forms as those will end up simply being lookups into the table.

[ntucker]

RFC to fix this and others in #760