Page MenuHomePhabricator

[web] Move `queuedChanges` state up from `ThreadSettingsModal` to `ConnectedThreadSettingsModal`
ClosedPublic

Authored by atul on Apr 18 2022, 11:38 AM.
Tags
None
Referenced Files
F3175311: D3760.diff
Thu, Nov 7, 8:04 PM
Unknown Object (File)
Tue, Nov 5, 1:47 AM
Unknown Object (File)
Sat, Nov 2, 12:29 PM
Unknown Object (File)
Thu, Oct 10, 2:51 AM
Unknown Object (File)
Thu, Oct 10, 2:51 AM
Unknown Object (File)
Thu, Oct 10, 2:51 AM
Unknown Object (File)
Thu, Oct 10, 2:51 AM
Unknown Object (File)
Thu, Oct 10, 2:50 AM

Details

Summary

Move currentTabType state out of the inner class component state, and move it out to the wrapping "Connected" functional component.

As part of the work to refactor ThreadSettingsModal… specifically to turn it into a functional component.


Depends on D3759

Test Plan

Was able to change settings in the ThreadSettingsModal and things continued to look/work as expected.

Diff Detail

Repository
rCOMM Comm
Branch
apr19 (branched from master)
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul published this revision for review.Apr 18 2022, 11:39 AM
tomek added inline comments.
web/modals/threads/thread-settings-modal.react.js
349–352 ↗(On Diff #11558)

I know this is pure refactor diff, but just wanted to let you know that there's an inconsistency in what we're storing in state. When we clear the state, we set it to Object.freeze({}), but when we update it, we no longer freeze. We should either always freeze or never.

I think it should be fine to avoid freezing, as ThreadChanges has readonly fields.

This revision is now accepted and ready to land.Apr 19 2022, 3:52 AM
web/modals/threads/thread-settings-modal.react.js
349–352 ↗(On Diff #11558)

Used Object.freeze() where it was used initially and ran into flow issues when I removed it:

1c31-1.png (876×1 px, 199 KB)


We should either always freeze or never.

Updating this diff to "freeze" everywhere.

Object.freeze() everywhere