settings: Add option to mark read on scroll only in conversation views#5469
Conversation
|
I see that the right-facing arrows aren't lined up. Let's check back in after #5446 is merged; I expect that to go in the right direction towards fixing that (see screenshots there), and may even be the right, complete fix. Marking as blocked on #5446, but we can still review wording, etc., in the meantime. |
| <IconRight size={kRightArrowIconSize} color={BRAND_COLOR} /> | ||
| <IconRight size={kRightArrowIconSize} color={themeData.color} /> |
There was a problem hiding this comment.
What's the effect of this first commit -- is there an existing screen where it changes something?
|
#5446 has been merged, so I think the next step is to rebase atop that and see how that alignment looks. |
56c1e95 to
d224289
Compare
Yep, I agree. I haven't yet checked the alignment in this latest revision—for now, this just resolves rebase conflicts, and adds two commits on top that convert to using Flow enums now that #5444 has landed. We can see how we like that for this use case. 🙂 For now I have to run, though. |
d224289 to
b6b5074
Compare
|
Thanks for the revision! Will take a look at the code momentarily. @alya, do you have any thoughts on the text in the new screen? See the lower-right screenshot in the first comment above. |
| export enum MarkMessagesReadOnScroll { | ||
| Always = 0, | ||
| Never = 1, | ||
| ConversationViewsOnly = 3, |
There was a problem hiding this comment.
Hmm -- why skip 2? Do the values end up mattering?
| migrations: { version: 52 }, | ||
| ...base37, |
There was a problem hiding this comment.
This will clobber migrations, no?
There was a problem hiding this comment.
Oops, I should switch the order of these two lines.
| dispatch(setGlobalSettings({ doNotMarkMessagesAsRead: value })); | ||
| dispatch( | ||
| setGlobalSettings({ | ||
| markMessagesReadOnScroll: MarkMessagesReadOnScroll.cast(value), |
There was a problem hiding this comment.
Hmm, awkward to have to do this. (Also the static casts (…: number) above.)
It looks like the root of this is that we say key={item.key} in SelectableOptionsScreen, passing these keys as React key pseudoprops. Ideally the type accepted there could be like "string, or number, or any enum of string or number", but there's no way to express the "any enum" part:
https://flow.org/en/docs/enums/using-enums/#toc-generic-enums
so it isn't.
I think in light of this bit I'd lean toward skipping the enum here, and sticking with the disjoint union of strings. There isn't a lot that we gain in this instance from the enum. But this price for using an enum isn't too bad, either.
Using the handy new InputRowRadioButtons component we added in edf5322. Fixes: zulip#5241
I checked, and no consumers were separately setting any padding on a component where this was being used. (If one did, then we'd want to investigate to see if this changed what padding was applied, e.g., because of how more-specific attributes prevail over less-specific ones.)
Now, there's less clicking required to check, by reading code, that the three components NestedNavRow, SwitchRow, and InputRowRadioButtons will look reasonably uniform. That's nice when they're all seen together, as they are when they make a list of settings on the settings screen (with the last of these being a newcomer there; see recent commits). This also continues our progress toward removing the constants in miscStyles.
And also for SelectableOptionsScreen, which this uses. These now match SelectableOptionRow, which has already been accepting `number`.
b6b5074 to
63f46eb
Compare
|
Thanks for the review! Revision pushed. |
|
Thanks! Looks good -- merging. @alya, if you have any thoughts on the settings text, happy to make a change. |
|
Sorry I missed the question earlier! I started a thread about tweaking the hint on CZO. |







Thanks to the handy new
InputRowRadioButtonscomponent we added in edf5322, this is now a quick user-visible feature we can check off the list.Screenshots below.
Fixes: #5241
Replaces: #5294