Page MenuHomePhabricator

[lib] Show sidebars in top level if parent thread is in a separate tab
ClosedPublic

Authored by will on Oct 15 2024, 2:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 22, 5:30 PM
Unknown Object (File)
Fri, Nov 22, 5:29 PM
Unknown Object (File)
Fri, Nov 22, 5:29 PM
Unknown Object (File)
Fri, Nov 22, 5:29 PM
Unknown Object (File)
Thu, Nov 21, 10:49 PM
Unknown Object (File)
Thu, Nov 21, 10:45 PM
Unknown Object (File)
Thu, Nov 21, 10:42 PM
Unknown Object (File)
Thu, Nov 21, 9:43 PM
Subscribers

Details

Summary

This shows sidebars on top level if their parent threads have a differing notif setting (home/mute).

In the next diff, the sidebar items listed under a parent that exist as top level items in a different tab will be removed

Test Plan

In a future diff, allowed the notif setting to be changed for sidebars. Tested the following

  • Confirmed that moving the child thread had it appear in a separate tab as a top level item
  • Confirmed that having a sidebar thread and its parent in the same tab did not result in a top level sidebar thread appearing
  • Confirmed moving the parent into the same tab caused the child to no longer appear as top level and into a different tab resulted in a top level item

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

lib/selectors/chat-selectors.js
274 ↗(On Diff #45211)

I went by threadIsHome to compare tabs. Do we ever plan to introduce more tabs than muted and home?

lib/shared/thread-utils.js
1430 ↗(On Diff #45211)

This allows sidebar threads to render and threadIsTopLevel filters them out

will marked an inline comment as not done.Oct 15 2024, 3:02 PM
will marked an inline comment as not done.
will added inline comments.
lib/shared/thread-utils.js
1430 ↗(On Diff #45211)

as**

will requested review of this revision.Oct 15 2024, 3:20 PM
ashoat requested changes to this revision.Oct 16 2024, 10:09 AM
ashoat added inline comments.
lib/selectors/chat-selectors.js
272 ↗(On Diff #45211)

Where did you get this type from? ?(ThreadInfo | RawThreadInfo)

273 ↗(On Diff #45211)

Why is optional chaining necessary here?

278 ↗(On Diff #45211)

In what scenario will isThreadInHome === undefined?

282 ↗(On Diff #45211)

It seems like we're making the filtering here stricter, even though our ultimate goal is to make it looser.

We're making it stricter here to compensate for the changes in getThreadListSearchResults, which makes the filtering a bit too loose (all sidebars are shown).

But getChatThreadItems is called from a bunch more places, and I suspect that they don't all go through getThreadListSearchResults:

# git grep chatListData
lib/selectors/chat-selectors.js:const chatListData: (state: BaseAppState<>) => $ReadOnlyArray<ChatThreadItem> =
lib/selectors/chat-selectors.js:  chatListData,
lib/shared/thread-utils.js:  chatListData: $ReadOnlyArray<ChatThreadItem>,
lib/shared/thread-utils.js:    return chatListData.filter(
lib/shared/thread-utils.js:  for (const item of chatListData) {
web/chat/thread-list-provider.js:  const chatListData = useFlattenedChatListData();
web/chat/thread-list-provider.js:  const chatListDataWithoutFilter = getThreadListSearchResults(
web/chat/thread-list-provider.js:    chatListData,
web/chat/thread-list-provider.js:    let threadListWithTopLevelItem = chatListDataWithoutFilter;
web/chat/thread-list-provider.js:    chatListDataWithoutFilter,
# git grep useFilteredChatListData
lib/hooks/child-threads.js:  useFilteredChatListData,
lib/hooks/child-threads.js:  const allSubchannelsList = useFilteredChatListData(filterSubchannels);
lib/hooks/search-threads.js:  useFilteredChatListData,
lib/hooks/search-threads.js:  const childThreadInfos = useFilteredChatListData(filterFunc);
lib/selectors/chat-selectors.js:  return useFilteredChatListData(threadInChatList);
lib/selectors/chat-selectors.js:function useFilteredChatListData(
lib/selectors/chat-selectors.js:  useFilteredChatListData,

It seems like your changes are going to make all of these have stricter filtering. What have you do to analyze and mitigate that risk?

This revision now requires changes to proceed.Oct 16 2024, 10:09 AM
will marked an inline comment as not done.Oct 16 2024, 11:10 PM
will added inline comments.
lib/selectors/chat-selectors.js
272 ↗(On Diff #45211)

This was discussed in-person. I made a mistake and this should have just been ThreadInfo

273 ↗(On Diff #45211)

It was not. Going with suggested approach

274 ↗(On Diff #45211)

We settled on keeping threadIsHome as threadInfo.currentUser.subscription.home is a boolean with muted being false. Therefore, checking tab by threadIsHome should be fine for now

278 ↗(On Diff #45211)

Leftover from a prior change. Changing in next rebase

282 ↗(On Diff #45211)

We settled on moving this code from getChatThreadItems (which has several different call sites unrelated to the current work) to the more specific getThreadListSearchResults which will return a helper function when empty search text.

lib/shared/thread-utils.js
1453

This ensures we also keep the 'seeMore' and 'spacer' sidebarItem types

Great work!

lib/shared/thread-utils.js
1425

Nit – since we're returning a new array here, and we don't care what the caller does with it, we could allow it to be mutable

1435

Nit

1437

Nit: we only need this inside the conditional below

1439

Nit: invert condition and early exit

This revision is now accepted and ready to land.Oct 17 2024, 6:25 AM
will marked 3 inline comments as done.

address nits

will marked an inline comment as done.Oct 17 2024, 9:58 AM
lib/shared/thread-utils.js
1437–1446 ↗(On Diff #45269)

Just a thought

lib/shared/thread-utils.js
1437–1446 ↗(On Diff #45269)

Thanks! I should be thinking of as many early exits as possible. This code is much more readable. Appending to next rebase before landing