8000 New design system colors by jovaniks · Pull Request #2309 · kickstarter/ios-oss · GitHub
[go: up one dir, main page]

Skip to content
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

New design system colors #2309

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

jovaniks
Copy link
Contributor

📲 What

Adaptive Colors system to have colors organized, and dynamic color retrieval from .xcassets.

  • Introduced a protocol-based approach to dynamically construct color names.
  • Implemented structured namespaces (background/, border/, text/) for clarity.

🛠 How

  • Created a AdaptativeColors protocol to handle color retrieval dynamically.
  • Defined Colors struct with namespaced enums (Background, Border, Text).
  • Implemented a single method (adaptative()) to fetch colors dynamically based on enum type.

👀 See

image

♿️ Accessibility

  • Supports Dark Mode via .xcassets.
  • Uses color contrast-aware asset catalog colors

✅ Acceptance criteria

  • Colors are retrieved correctly based on the namespace (background/, border/, text/).
  • No breaking changes to existing UI elements.

⏰ TODO

  • Gather feedback from designers to ensure correct color mapping.

@jovaniks jovaniks self-assigned this Feb 27, 2025
@jovaniks jovaniks changed the title Jluna/mbl 2045/adaptive colors New design system colors Feb 27, 2025
case is Colors.Text.Type:
namespace = "text/"
default:
namespace = ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on this PR it looks like all the colors are defined in those three prefixes, which would suggest that we wouldn't expect the default case to be hit. Is that correct? If this should NOT be hit and we cant count on the compiler catching it, can we add an assertion failure here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point! However, I think we should keep the default case without an assertionFailure because we might want to define new color categories outside of a namespace.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do that in the future, someone adding those colors would hit the assertion and they could remove it. In the current state of the code it looks like a mistake to add it here, so IMO it should get treated that way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. I see your reasoning here, and it makes sense to catch unexpected cases early rather than silently defaulting to an empty namespace. I'll go ahead and add the assertionFailure to make it more explicit when a new color category is introduced outside of the expected namespaces.

let colorName = "\(namespace)\(self.rawValue)"

// Retrieves the color from the asset catalog, defaulting to white if unavailable.
return UIColor(named: colorName) ?? .white
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly add an assertion failure here if we don't get that named color.

@nativeksr
Copy link
Collaborator
nativeksr commented Mar 10, 2025
1 Warning
⚠️ Big PR

Generated by 🚫 Danger

Copy link
Contributor
@amy-at-kickstarter amy-at-kickstarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one non-blocking nitpick.

}

assertionFailure("⚠️ Color not found in asset catalog: \(colorName)")
return .white
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: since most colors are used for text and UI elements, instead of backgrounds, it would be better if this was a color visible on the background. How about returning a default kickstarter green? But this is an edge case, I assume with the assert we'd never get here. 🤷‍♀️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was returning .white thinking of a neutral color, but I kind of agree — returning a green would likely be more visible in most cases. Which green are you thinking of, .ksr_create_700?

case facebookDefault
case inverseDisabled
case inversePressed
case surfacePrimary
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does surface mean here? Is this a background?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's correct, surface refers to a background color, which is why it's under the Colors.Background enum. The idea is to stay consistent with the naming conventions used in Figma.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0