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
Unknown Object (File)
Tue, Dec 3, 4:26 PM
Unknown Object (File)
Sat, Nov 30, 5:48 AM
Unknown Object (File)
Sat, Nov 30, 4:46 AM
Unknown Object (File)
Sat, Nov 30, 2:20 AM
Unknown Object (File)
Nov 27 2024, 12:50 AM
Unknown Object (File)
Nov 27 2024, 12:50 AM
Unknown Object (File)
Nov 15 2024, 6:09 AM
Unknown Object (File)
Nov 13 2024, 12:50 PM

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
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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