Consume more tokens from arches theme, add dark mode toggle

[jacobtylerwalls]

Fix header skip closes #87
Add dark mode toggle closes #91

[jacobtylerwalls]

With this change, there's now a difference (on my local browser) between semibold and bold. (sans-serif in my browser was lacking a weight value for 600). Which means: we can preset the font weight for button labels to 600/semibold without it being too loud (it was looking the same as bold)

Then we'll have a default for button labels that looks good both in the controlled list manager (arches chrome) and here.

[chrabyrd]

Eh I'd say remove system-ui, as that varies from system to system and pulls us away from a unified experience. https://infinnie.github.io/blog/2017/systemui.html

[jacobtylerwalls]

Yeah I saw that also, but I can't remember if I saw that before or after I made this addition, 😄 . I'll back it out. You have a good point we're building a unified experience, not a blog for a law office.

[jacobtylerwalls]

Wanted to deemphasize these buttons.

[jacobtylerwalls]

Without using the label prop, it wasn't using the tokens for button label font weight (not noticeable until I started overriding that weight via the theme)

[chrabyrd]

looks like some webpack failures in the CI?

[jacobtylerwalls]

That's expected, since this depends on themes/default.ts in archesproject/arches#11319. I could update this branch to depend on it, but that seems like avoidable churn?

[chrabyrd]

For whatever reason, the toggle doesn't work for me. Also would it go into this ticket or a followup to have the basic search component handle theming?

[chrabyrd]

Eh I'd say remove system-ui, as that varies from system to system and pulls us away from a unified experience. https://infinnie.github.io/blog/2017/systemui.html

[jacobtylerwalls]

Also would it go into this ticket or a followup to have the basic search component handle theming?

Let's do a follow up, could be good to onboard another team member onto theming stuff?

[jacobtylerwalls]

For whatever reason, the toggle doesn't work for me.

Yowza! I guess... do you have any manual overrides of the dev/8.0.x arches theme? I know on your system you did some deep dives into css reset for vue, so I'm wondering if you had any artifacts from that lying around, like css layers or something.

[chrabyrd]

boo failing builds

[chrabyrd]

For whatever reason, the toggle doesn't work for me.

Yowza! I guess... do you have any manual overrides of the dev/8.0.x arches theme? I know on your system you did some deep dives into css reset for vue, so I'm wondering if you had any artifacts from that lying around, like css layers or something.

oh huh. after you pulled main into the branch things are working now 🎉

[chrabyrd]

Looks good! Some minor nits will probably fall out once this is moved out of lingo, but I'm not worrying about those now.

There's some additional complexity that's fallen out of this review, but happy to chat or kick parts of it to a follow-up 👍

[chrabyrd]

isDarkModeEnabled works! (🎉 ). However, regardless of if its value, the theme when the page is loaded is always light. I was able to solve this locally via

onMounted(() => {
    if (isDarkModeEnabled.value) {
        toggleDarkMode();
    }
});

However, this may not be the right solution. There's further complexity to add that may nullify that pattern. Namely, I can set the toggle to dark, see the change, refresh the page, and it's automatically set back to light. My guess is that either cookies or localstorage need to be leveraged to persist this through page refreshes.

If we wanted to get really fancy we could add a column to the User model to support preferred theme, but that's probably overkill at this point. And we'd still need something on the browser to persist for anonymous user so /shrug that's not an entirely baked idea.

If this component is changed to read from cookies/localstorage on mount, it'd be more readable to change the toggle method to accept an arg so it can be explicitly set the mode. This will also support adding other themes later. However I'm not married to this pattern, YAGNI and whatnot /shrug. Regardless, reading from cookies/localstorage nullifies the simple code laid out above.

But this reveals another titchy thing: we're handling all of theming in this component. If I have a cookie ( or bit of localstorage ) saved that says I prefer dark mode, I'd expect the application to handle this regardless of the presence or absence of the header / DarkModeToggle. Like in reports and whatnot. It could be argued that the ability to switch themes should be handled in this component of course, but the ability to query a preferred theme and apply it should be handled at a deeper level.

Perhaps even in core since it's touching the <html> element, but I don't feel strongly about that yet.

[jacobtylerwalls]

boo failing builds

I'll update the github action. Maybe we need the updateproject command to yell about this again when the github templates change?

[jacobtylerwalls]

The actions are dense; better to just call out the tiny change in the upgrade instructions.

[chrabyrd]

The actions are dense; better to just call out the tiny change in the upgrade instructions.

IMO it should be automated, part of the updateproject command. The odds that people have changed their project's specific actions are low, but we should definitely call out a warning as part of the initial update project warning. Happy to crank this out in core. WDYT?