Page MenuHomePhabricator

[web] Move `namePlaceholder` up from `ThreadSettingsModal` to `ConnectedThreadSettingsModal`
ClosedPublic

Authored by atul on Apr 18 2022, 12:46 PM.
Tags
None
Referenced Files
F3558424: D3762.diff
Fri, Dec 27, 3:00 AM
Unknown Object (File)
Fri, Dec 20, 1:12 AM
Unknown Object (File)
Tue, Dec 10, 11:22 PM
Unknown Object (File)
Fri, Dec 6, 9:16 PM
Unknown Object (File)
Fri, Dec 6, 9:16 PM
Unknown Object (File)
Fri, Dec 6, 4:37 PM
Unknown Object (File)
Nov 18 2024, 1:52 PM
Unknown Object (File)
Nov 13 2024, 12:50 PM

Details

Summary

Move namePlaceholder out from inner class component to outer "Connected" functional component.

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


Depends on D3760

Test Plan
  1. Opened ThreadSettingsModal for a thread
  2. Ensured that the placeholder was as expected

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul requested review of this revision.Apr 18 2022, 12:52 PM
tomek requested changes to this revision.Apr 19 2022, 4:00 AM
tomek added inline comments.
web/modals/threads/thread-settings-modal.react.js
444–449

We can't have an invariant here: we explicitly handle !threadInfo case in the next line, so it should be a big warning that something is really wrong. Another warning is that the original code didn't need an invariant - why was that?

It looks like we should instead have a condition which returns robotextName or an empty / predefined string depending on the presence of threadInfo.

It would be hard to catch this during testing, but looking at the message from the if it sounds like when a user has this component opened and is removed from it by someone else, we would call an invariant.

This revision now requires changes to proceed.Apr 19 2022, 4:00 AM
atul requested review of this revision.Apr 19 2022, 9:42 AM
atul added inline comments.
web/modals/threads/thread-settings-modal.react.js
444–449

Sorry, I should have explained this more clearly.

This invariant is temporary and will be removed once namePlaceholder has been pushed down to the ThreadSettingsGeneralTab component.

We can't move namePlaceholder below the early !threadInfo return because of the "rules of hooks," so it needs to be defined above that check. However, where namePlaceholder is defined right now it's possible for threadInfo to be null/undefined. But, because we know that this function will only ever be called from within the inner ThreadSettingsModal, we can be assured that threadInfo will be defined and use an invariant.


In subsequent diffs this functionality will be pushed down to ThreadSettingsGeneralTab where we are assured that threadInfo is defined and can remove the invariant.


Another warning is that the original code didn't need an invariant - why was that?

The original code didn't need an invariant because it lived within the inner ThreadSettingsModal component where the threadInfo can't be null/undefined.

tomek added inline comments.
web/modals/threads/thread-settings-modal.react.js
444–449

Thanks for the explanation!

But, because we know that this function will only ever be called from within the inner ThreadSettingsModal, we can be assured that threadInfo will be defined and use an invariant.

Ok, that makes sense. If that wasn't the case, I would prefer returning an empty string instead of invariant - just to don't break the existing code.

This revision is now accepted and ready to land.Apr 20 2022, 9:56 AM

If that wasn't the case, I would prefer returning an empty string instead of invariant

Yeah I agree, this will be moved to the ThreadSettingsGeneralTab soon at which point we'll be able to cut the invariant.

This revision was landed with ongoing or failed builds.Apr 20 2022, 11:42 AM
This revision was automatically updated to reflect the committed changes.