feat: add new messages to ui as soon as theyre sent without waiting for subscribtion update

[pie6k]

What changed:

Before: after sending a new message, it was not showing in the UI until the socket subscription picked it. Hasura has 1s socket interval so it often had a visual delay

Now: as soon as mutation resolved, data from mutation is added to the temporary list of 'optimistic messages' to display in the UI .

[linear]

ACA-274 Messages subscribtion should instantly add newly added messages

[koliada]

By looking at this PR I was feeling there must be a more generic way. And I found this, did you try it?
https://www.apollographql.com/docs/react/performance/optimistic-ui/

[pie6k]

Yeah, I tried with that and with direct cache access.
apollographql/apollo-kotlin#1722
apollographql/apollo-client#5267

It turned out it works with queries, not subscriptions ¯_(ツ)_/¯

I had some other thoughts how to do it in 'generic way'.

My idea was to use both query and subscribtion at the same time (hasura allows that, you only have to gql.replace(query, subscribtion) and then return 'the newest value' out of both. This way I could update query cache with optimistic update and it would be 'newer value' until next value from subscribtion arrives.

Then I thought to start simple and add some solution like above if more similar use-cases emerge.

But TBH I'm not sure and I'm not fully happy with this PR too.

[koliada]

The fact we need to follow the payload schema with the __typename: "message" property is the biggest red flag here to me. Any other solution which doesn't require manual state composition should be better, IMHO.

[koliada]

Basically, the solution presented in the PR is not sustainable enough.

[heikir]

Looks good overall.

[heikir]

I agree with @koliada . The PR looks ok, but implementing the other way solution and making it generic so that it could be applied in the future in other components probably makes more sense.

[koliada]

Please try to sort the manually added dependencies for better visibility :)

[heikir]

@pie6k what's your take on this? Would you like to re-implement this or leave it be for now? I don't have a strong opinion on this.

[pie6k]

I think I'll re-implement and use this opportunity to organize graphql definitions and hooks in a bit different way (we've been discussing it a bit recently, but I can elaborate)

[heikir]

Sounds good. Writing it down, what you would like to change, would help me to participate in the discussion.

[pie6k]

Fair, added context to https://meetnomore.com/room/ptTTTfy12hdK3mv347R5 > graphql agenda point (:< not able to get link to agenda point)

[pie6k]

I'll redo this work with different graphql approach