-
-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
settings: Add option to mark read on scroll only in conversation views #5469
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the effect of this first commit -- is there an existing screen where it changes something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks. Seems good.
#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. |
src/reduxTypes.js
Outdated
export enum MarkMessagesReadOnScroll { | ||
Always = 0, | ||
Never = 1, | ||
ConversationViewsOnly = 3, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm -- why skip 2? Do the values end up mattering?
migrations: { version: 52 }, | ||
...base37, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will clobber migrations
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I should switch the order of these two lines.
src/settings/SettingsScreen.js
Outdated
dispatch(setGlobalSettings({ doNotMarkMessagesAsRead: value })); | ||
dispatch( | ||
setGlobalSettings({ | ||
markMessagesReadOnScroll: MarkMessagesReadOnScroll.cast(value), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
InputRowRadioButtons
component we added in edf5322, this is now a quick user-visible feature we can check off the list.Screenshots below.
Fixes: #5241
Replaces: #5294