Page MenuHomePhabricator

[web] Leave `ThreadSettingsGeneralTab` open after settings are saved
ClosedPublic

Authored by abosh on Jun 30 2022, 11:30 AM.
Tags
None
Referenced Files
F3515612: D4416.diff
Sun, Dec 22, 9:20 AM
F3514327: D4416.id14041.diff
Sun, Dec 22, 4:07 AM
Unknown Object (File)
Mon, Dec 9, 5:50 AM
Unknown Object (File)
Tue, Dec 3, 12:29 PM
Unknown Object (File)
Nov 10 2024, 9:12 AM
Unknown Object (File)
Nov 10 2024, 9:12 AM
Unknown Object (File)
Nov 8 2024, 12:50 PM
Unknown Object (File)
Nov 8 2024, 12:50 PM
Subscribers

Details

Summary

Relevant Linear issue here. Leaves ThreadSettingsGeneralTab open after hitting the "Save" button. This ensures that the user can make any more changes if they'd like to even after clicking "Save" without having to reopen the modal manually.


Will add a nicer transition to the Save button in a subsequent diff. See Linear issue for that here.

Test Plan

Looks and works as expected on Chrome/Safari:

Diff Detail

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

Event Timeline

tomek added a reviewer: ashoat.

This design works ok, but have an important downside: it's not clear which changes were already committed and which will be after clicking save button. The previous design was also affected, but after each save a user had to open the modal again and see the current server state. It might be even more confusing when there was an error.
I think it could be a good idea to somehow mark uncommitted changes.
Also, the save button is always enabled - I think that disabling it when there are no pending changes would make this better.

web/modals/threads/settings/thread-settings-general-tab.react.js
105–109 ↗(On Diff #14041)

We can simplify it now.

it's not clear which changes were already committed and which will be after clicking save button. The previous design was also affected, but after each save a user had to open the modal again and see the current server state. It might be even more confusing when there was an error.

This is a great observation. I think your suggestion:

I think it could be a good idea to somehow mark uncommitted changes.

is a good one. However, at least for now, the ThreadSettingsGeneralTab automatically updates once a change is made. By that I mean if the user decides to update the thread name, thread description, or thread color those are all changes they make and see inside the modal. So disabling the Save button should be enough to convince the user their changes were committed. That way, if they make another change the button will become enabled, and they will know that they have uncommitted changes. I can handle that (disabling the save button when there are no pending changes) in a subsequent diff, although I think it is very connected to this diff.

Simplify return value of changeThreadSettingsAction, per inline feedback

So disabling the Save button should be enough to convince the user their changes were committed. That way, if they make another change the button will become enabled, and they will know that they have uncommitted changes. I can handle that (disabling the save button when there are no pending changes) in a subsequent diff, although I think it is very connected to this diff.

This sounds like a good compromise solution that should be easy to implement. @yayabosh, can you create a Linear task for this follow-up?

This revision is now accepted and ready to land.Jul 2 2022, 6:48 PM