feat: Use system default color mode, but allow user override

[ericvolp12]

I've implemented a fix for #682 using radio buttons and moved the setting to the Settings page as suggested in the comments below:

The default is currently system so new users will be using their device default themes when launching the app for the first time but after changing it, will have their preferences stored in the shell state.

OLD:
I've implemented a fix for #682 that doesn't use a radio group but cycles through 3 modes ['light', 'dark', 'system'] and the system mode inherits the device theme properly.

Video Demo:

When system default theme is dark:

When system default theme is light:

Regardless of the system default theme:

Tested in mobile browser as well and it inherits an android device theme properly.

Couldn't get the expo test app to work on my phone yet but I did update the Native components so they should expose the same behavior.

This change doesn't change the colorScheme at all, it just updates how the colorScheme is set in ThemeContext.tsx so that we inherit if the user has chosen system as their theme.

We also default in shell.ts to use the system theme to conform to user expectations.

[ansh]

I have identical code to this for this issue. The problem is a UX one. It's hard to express to users that a singular icon button is a 3-way toggle between light/dark/system on mobile. It's more verbose on web so easier to understand for sure.

[ericvolp12]

I took another whack at it using a 3-state radio button, I can't test on mobile at the moment though.

[ericvolp12]

Current mobile web looks like:

[notdaniel]

It's hard to express to users that a singular icon button is a 3-way toggle between light/dark/system on mobile.

I think users are used to the word "automatic" in reference to system theme. Paired with the right icon, it would work fine.

So I notice that a moon icon is being used above, even for daytime. If you switched it to a sun icon, then you could use them this way:

• ☼ Light Theme
• ☾ Dark Theme
• ☼/☾ Automatic

I find the text-only buttons to be way less intuitive, personally

[pfrazee]

I appreciate what you're aiming for here!

Yeah I think the 3-way state is a bit of a challenge. Maybe we move it out of the drawer/right-nav and into the settings?

[parion]

Maybe we move it out of the drawer/right-nav and into the settings?

That's what I was thinking too, something ala this in a Display menu.

[ericvolp12]

I appreciate what you're aiming for here!

Yeah I think the 3-way state is a bit of a challenge. Maybe we move it out of the drawer/right-nav and into the settings?

I'll take a swing at it after $dayjob, I like that idea too because it lets us put the control in the same place on both web and native.

[snhasani]

@ericvolp12 I cocked these codes last night. But in the end I wasn't happy about the result because of the poor UI and UX. So I didn't create a PR for here but you can check my code and maybe reusing some part of it. I refactor the SelectableButton component and create a new one, GroupButton. And some other stuff.

I think we can put appearance settings into a modal like a few of current settings. Like twitter iOS dark mode settings:

P.S: Running iOS or Android is a pain in ass. I couldn't run them after a couple of hours of miserable tries. It is too hard to contribute on something that you can not run it :D

cc @pfrazee @ansh

[ericvolp12]

Okay, I've moved the appearance 3-way-toggle to the Settings page and removed it from the other components.

[snhasani]

Good job! Added a couple of comments.

[snhasani]

IMO colorMode isn't an intelligible name for something that we call in UI as appearance setting. For me color mode looks like a variable that contains an accent color of the current color scheme. Right now we have only one accent color for each light and dark color scheme. We don't need to have a variable for that now. But in the future when we add it then we don't need to touch this flag. I think appearance is more clear than colorMode in this context.

export const APPEARANCE = {
  SYSTEM: 'system',
  DARK: 'dark',
  LIGHT: 'light',
} as const

type ObjectValues<T> = T[keyof T]

export type AppearanceType = ObjectValues<typeof APPEARANCE>

export class ShellUiModel {
  appearance: AppearanceType
   ...
}

[pfrazee]

I get this concern but I don't think it's confusing enough to change

[snhasani]

Here is an opportunity for refactoring and preventing duplicate codes. You can pull out SelectableBtn from src/view/com/modals/ContentFilteringSettings.tsx and create a new one component that reused here and there.

You can use my code from this and this commit. It's already there.

[rezaaa]

Good job guys. I hope you change the component design to something better.

[pfrazee]

Awesome, thanks everybody