Page MenuHomePhabricator

[lib] Split implementations of `[client/server]ThreadInfoFromRawThreadInfo`
AbandonedPublic

Authored by atul on Mar 14 2024, 11:53 AM.
Tags
None
Referenced Files
F3527952: D11333.id38084.diff
Tue, Dec 24, 7:33 AM
F3527941: D11333.id.diff
Tue, Dec 24, 7:33 AM
F3527925: D11333.diff
Tue, Dec 24, 7:32 AM
F3525847: D11333.diff
Mon, Dec 23, 6:32 PM
Unknown Object (File)
Tue, Dec 10, 9:36 PM
Unknown Object (File)
Sat, Nov 30, 10:08 AM
Unknown Object (File)
Nov 8 2024, 6:46 AM
Unknown Object (File)
Oct 15 2024, 8:18 PM
Subscribers

Details

Summary

We compute currentUser with CHANGE_ROLE approximation on server (for now), and will computer currentUser using communityThreadInfo on client.

Where are usages of clientThreadInfoFromRawThreadInfo??

Each of the callsites that will need to have serverThreadInfoFromRawThreadInfo -> clientThreadInfoFromRawThread require a good amount of work. I think it makes sense to split implementations of *ThreadInfoFromRawThreadInfo in one diff and handle the callsites separately. Especially because for some callsites we need to recursively update their own callsites.

The callsites that will be updated are:

  • threadInfoSelector
  • createPendingThread

Depends on D11318

Test Plan

Updated callsites to use both server* and client* variants of the function naively and set breakpoint to ensure things worked as expected.

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul requested review of this revision.Mar 14 2024, 12:09 PM
tomek added inline comments.
lib/selectors/thread-selectors.js
73

It doesn't sound right to use server function in a client selector. Maybe we can find a better name?

This revision is now accepted and ready to land.Mar 19 2024, 5:21 AM

We ended up going with a very different approach from this stack. Abandoning to tidy things up.