Page MenuHomePhabricator

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

Authored by atul on Jun 3 2024, 1:03 PM.
Tags
None
Referenced Files
F3376407: D12288.diff
Tue, Nov 26, 11:47 PM
Unknown Object (File)
Sat, Nov 23, 12:44 PM
Unknown Object (File)
Fri, Nov 22, 8:33 PM
Unknown Object (File)
Sat, Nov 16, 6:19 AM
Unknown Object (File)
Sun, Nov 10, 4:32 PM
Unknown Object (File)
Sun, Nov 10, 9:40 AM
Unknown Object (File)
Sun, Nov 10, 8:00 AM
Unknown Object (File)
Fri, Nov 8, 1:52 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
arcpatch-D12288 (branched from 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 ↗(On Diff #40897)

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 ↗(On Diff #40897)

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 ↗(On Diff #40897)

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.