Page MenuHomePhabricator

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

Authored by atul on Jun 3 2024, 1:03 PM.
Tags
None
Referenced Files
F3350062: D12288.diff
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
Unknown Object (File)
Fri, Nov 8, 7:15 AM
Unknown Object (File)
Fri, Nov 8, 7:15 AM
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
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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.