Page MenuHomePhabricator

[lib] Consume `useThreadFrozenDueToViewerBlock` in `web/ChatInputBar`
ClosedPublic

Authored by atul on Jun 3 2024, 1:03 PM.
Tags
None
Referenced Files
F3150219: D12288.id41354.diff
Mon, Nov 4, 10:40 PM
Unknown Object (File)
Thu, Oct 10, 10:53 PM
Unknown Object (File)
Thu, Oct 10, 10:53 PM
Unknown Object (File)
Thu, Oct 10, 10:52 PM
Unknown Object (File)
Wed, Oct 9, 3:45 PM
Unknown Object (File)
Tue, Oct 8, 8:26 PM
Unknown Object (File)
Mon, Oct 7, 11:44 PM
Unknown Object (File)
Mon, Oct 7, 10:42 PM
Subscribers
None

Details

Summary

Consuming hook similar to D12287 in web/ChatInputBar and then removing threadFrozenDueToViewerBlock altogether since it is no longer used.


Depends on D12287

Test Plan

flow and basic logging in hook and in ChatInputBar component

Diff Detail

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

Event Timeline

atul published this revision for review.Jun 3 2024, 1:04 PM
tomek added inline comments.
web/chat/chat-input-bar.react.js
691

Should we keep the longer name threadFrozenDueToViewerBlock?

This revision is now accepted and ready to land.Jun 4 2024, 1:24 AM
ashoat added inline comments.
web/chat/chat-input-bar.react.js
347–350

Can you reevaluate whether each of these props still need to be passed to the class component? It looks like at least communityThreadInfo can be removed, for instance

rebase before addressing feedback + landing

remove communityThreadInfo and userInfos props

atul added inline comments.
web/chat/chat-input-bar.react.js
691

Figured threadFrozen was more concise and the reasoning for thread being frozen doesn't matter "inside" the component?

Can put up followup changing to threadFrozenDueToViewerBlock is that's preferred.

This revision was landed with ongoing or failed builds.Jun 16 2024, 5:06 PM
This revision was automatically updated to reflect the committed changes.