- We rename existing threadInfoFromRawThreadInfo to baseThreadInfoFromRawThreadInfo
- We introduce threadInfoFromRawThreadInfo which computes currentUser with getMinimallyEncodedCurrentUser and passed to baseThreadInfoFromRawThreadInfo
What's the motivation for doing this?
Right now threadInfoFromRawThreadInfo is used on both client and server. However, we want to split the implementation into a serverThreadInfoFromRawThreadInfo and clientThreadInfoFromRawThreadInfo. We want to share as much code as possible, so we're going to create a client and server wrapper function over baseThreadInfoFromRawThreadInfo where we pass in a "pre-computed" currentUser.
Why do we need to split functionality between client and server?
- The primary motivation of the specialRole work is to reduce the size of role/permissions data stored in Redux on the clients.
- By updating memberHasAdminPowers and appendUserInfo to depend on community root roles instead of computed member.permissions, we can avoid storing/persisting/sending that data to the clients.
- On the clients we can compute memberHadAdminPowers using community root threadInfo which we have access to via Redux ThreadStore.
- HOWEVER, things are not so easy on the keyserver. There are many callsites that eventually call threadInfoFromRawThreadInfo where we do NOT have access to community root threadInfo.
- Updating all of the callsites to have access to community root threadInfo would be quite involved. I tried doing that yesterday (Tuesday), and the scope quickly grew out of control. We'd have to update a bunch of queries, types, intermediate functions, etc. It seems like a project of its own.
- I think the most pragmatic way forward, and way to achieve the primary goal of removing computed member.permissions from client stores, is to focus on updating everything on the client and deferring things on the keyserver.
- This means that for the timebeing, the memberHasAdminPowers check will continue using the CHANGE_ROLE approximation on keyserver.
- I think updating keyserver memberHasAdminPowers checks to use roles will require a lot of work and effectively be its own project. I think this would fit naturally with the "minimal permissions in memberships table" work.
NOTE: TLDR: I think the most pragmatic solution is to use communityThreadInfo.roles to compute memberHasAdminPowers on client, while it makes sense to keep using CHANGE_ROLE check on keyserver for the timebeing. This will mean that the logic will diverge. I think in practice it should be fine since we've been using the CHANGE_ROLE approximation this whole time and will be doing something "more robust" on the client
Depends on D11317