-
Notifications
You must be signed in to change notification settings - Fork 734
Support retrieving color JS value #1956
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
Conversation
changeListeners: SchemeChangeListener[] = []; | ||
private currentScheme: SchemeType = 'default'; | ||
private schemes: Schemes = {light: {}, dark: {}}; | ||
private schemesJS: Schemes = {light: {}, dark: {}}; |
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.
I don't understand how schemesJS
is different from schemes
... why we need the two?
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.
Did you look how do we store each in loadScheme
method? we store different values in some use cases
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.
Yes
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.
Basically in schemes
we keep the native platformColors
The values that are kept there are not regular strings but a weird object that the native side can handle
That's the reason I also want to keep the plain JS strings in schemesJS
It should serve the Colors.getColorValue
method when we need to get the original JS string hex value in some cases.
Why do we need the JS string value?
One of the cases, is when we call the Colors.getColorTint
in the private repo.
With the recent PlatformColor support, this method throws an error because Colors.getColorTint
expect a string but now gets a weird object.
So this whole PR meant to let us get the original string value so we can pass to Colors.getColorTint
I hope this explains better
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.
Sorry I wasn't clear with my question. I understand the meaning behind the pr and why we want to keep the js schemes. What I was missing is where are you loading these schemesJS with the string values.
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.
Anywhere we call Colors.loadSchemes
(It calls internally Scheme.loadSchemes
) and it always accept a maps of strings colors.
We internally mapped them once to platform colors or strings
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.
Ok
Description
Support retrieving the original string value of color by its key
Good for need to make calculate on the color hex string and want to get it instead of the native platformColor
Changelog
Added Colors.getColorValue - Support retrieving the original string value of color by its key