Page MenuHomePhabricator

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

Authored by atul on Mon, Jun 3, 1:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jun 21, 10:30 AM
Unknown Object (File)
Fri, Jun 21, 6:23 AM
Unknown Object (File)
Fri, Jun 21, 6:23 AM
Unknown Object (File)
Fri, Jun 21, 6:23 AM
Unknown Object (File)
Thu, Jun 20, 4:37 AM
Unknown Object (File)
Sat, Jun 15, 6:00 AM
Unknown Object (File)
Sat, Jun 15, 1:33 AM
Unknown Object (File)
Fri, Jun 14, 10:26 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.Mon, Jun 3, 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.Tue, Jun 4, 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.Sun, Jun 16, 5:06 PM
This revision was automatically updated to reflect the committed changes.