chore: handle invites to projects

[cimigree]

closes #42
Adds files to listen for invites, handle them when they come in, and accept or reject an invite to a project.
Used this notion doc: https://www.notion.so/digidem/Desktop-Invites-Architecture-15a1b08162d58053b27dd7b6133e7e33

[achou11]

Only an initial code review and didn't actually try out the feature (can I even do that?).

Upgrading to @comapeo/core-react to v2 will reduce the diff here a bit. I have a separate PR for that via #85

Didn't take a good look at the test just yet but I think our testing setup needs to be improved in order to make it less tedious to write (Erik had started work on it but I think it's worth revisiting - I had lots of feedback on it and might just work on it myself)

[achou11]

Unnecessary spread operator

Suggested change

	return useSuspenseQuery({
	...pendingInvitesQueryOptions({ clientApi }),
	})
	return useSuspenseQuery(
	pendingInvitesQueryOptions({ clientApi }),
	)

[achou11]

might want to consider having this hook implemented in a way similar to what's outlined in digidem/comapeo-core-react#8, the main difference being adding a listener that invalidates the relevant query cache.

Ideally implementing this yourself isn't needed - but haven't gotten around to doing it yet 😬

[cimigree]

Ok I tried to do this and the dedupe...Will be curious if I did it as you imagined.

[achou11]

Seeing if (invite) { ... } within event handlers and fallbacks in the render body to account for the invite no longer being available is usually a smell to me. Would suggest accounting for the two discrete states explicitly and separately:

1. When the invite is no longer available and cannot be responded to
2. When the invite is available and can be responded to

Something along the lines of this:

function JoinProjectScreenComponent() {
    // Same logic as you currently have for getting the inviteId and all
    const invite = pendingInvites.find((i) => i.inviteId === inviteId)
  
    // If the associated invite is no longer available, render content that's specific to that state
    if (!invite) {
      return <div>...</div>
    }
    
    // Otherwise, render the content as though the invite is still valid
    return <div>...</div> 
}

This becomes less prone to type-related issues and workarounds, as well as a clearer UI. There may be some parts of the screen that are the same in both of the states (duplication is fine IMO), but for example it doesn't make sense to render the buttons if we know that pressing them won't do anything because the invite is no longer valid. Not detailed in the design but I think that's a fair observation 😄

[cimigree]

Ok. UI is not awesome, but it is basic and is there. Will wait for a design and the proper wording before I spend more time thinking about it.

[cimigree]

@achou11 I did as you requested, but I also added a Dev feature to be able to simulate an invite... Seen on every screen but it only works on the CreateJoin Project screen.
When you click it once, it takes you to the invite not found screen.
When you click it once you are on that screen, you can see the actual Join Project Screen.
The buttons to accept or decline do nothing except log the error.
I left the other logic there to be valid when a real invite is emitted and the other logic that works for dev simulation.

[ErikSin]

Hey, thanks for all the work on this. Gregor and I realized that there are some blockers with this architecture. If we delete CoMapeo on desktop, we don't actually delete the data. This would mean if the user tries to delete CoMapeo in order to get back to the "join a project screen", it would not work. Lets put a pause on this work as we will need to change the design to account for this.

Thanks for doing the work and sorry that we caught this a little too late.