Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
/**
|
2018-09-12 01:27:47 +03:00
|
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
*
|
2018-02-17 05:24:55 +03:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
*
|
2018-05-11 05:06:46 +03:00
|
|
|
* @format
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
* @flow
|
|
|
|
*/
|
2018-05-11 05:06:46 +03:00
|
|
|
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
/* eslint no-bitwise: 0 */
|
2019-10-16 20:03:47 +03:00
|
|
|
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
'use strict';
|
|
|
|
|
PlatformColor implementations for iOS and Android (#27908)
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
2020-03-03 02:07:50 +03:00
|
|
|
import type {ColorValue} from './StyleSheetTypes';
|
|
|
|
import type {ProcessedColorValue} from './processColor';
|
|
|
|
|
|
|
|
function normalizeColor(
|
|
|
|
color: ?(ColorValue | ProcessedColorValue),
|
|
|
|
): ?ProcessedColorValue {
|
2018-06-02 03:48:58 +03:00
|
|
|
const matchers = getMatchers();
|
2018-05-11 01:44:52 +03:00
|
|
|
let match;
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
|
2016-02-08 15:04:01 +03:00
|
|
|
if (typeof color === 'number') {
|
|
|
|
if (color >>> 0 === color && color >= 0 && color <= 0xffffffff) {
|
|
|
|
return color;
|
|
|
|
}
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
PlatformColor implementations for iOS and Android (#27908)
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
2020-03-03 02:07:50 +03:00
|
|
|
if (typeof color === 'object' && color != null) {
|
|
|
|
const normalizeColorObject = require('./PlatformColorValueTypes')
|
|
|
|
.normalizeColorObject;
|
|
|
|
|
|
|
|
const normalizedColorObj = normalizeColorObject(color);
|
|
|
|
|
|
|
|
if (normalizedColorObj != null) {
|
|
|
|
return color;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (typeof color !== 'string') {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
// Ordered based on occurrences on Facebook codebase
|
|
|
|
if ((match = matchers.hex6.exec(color))) {
|
2016-02-08 15:04:01 +03:00
|
|
|
return parseInt(match[1] + 'ff', 16) >>> 0;
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (names.hasOwnProperty(color)) {
|
|
|
|
return names[color];
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.rgb.exec(color))) {
|
|
|
|
return (
|
2018-05-11 05:06:46 +03:00
|
|
|
// b
|
|
|
|
((parse255(match[1]) << 24) | // r
|
|
|
|
(parse255(match[2]) << 16) | // g
|
|
|
|
(parse255(match[3]) << 8) |
|
|
|
|
0x000000ff) >>> // a
|
|
|
|
0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.rgba.exec(color))) {
|
|
|
|
return (
|
2018-05-11 05:06:46 +03:00
|
|
|
// b
|
|
|
|
((parse255(match[1]) << 24) | // r
|
|
|
|
(parse255(match[2]) << 16) | // g
|
|
|
|
(parse255(match[3]) << 8) |
|
|
|
|
parse1(match[4])) >>> // a
|
|
|
|
0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.hex3.exec(color))) {
|
2018-05-11 05:06:46 +03:00
|
|
|
return (
|
|
|
|
parseInt(
|
|
|
|
match[1] +
|
|
|
|
match[1] + // r
|
|
|
|
match[2] +
|
|
|
|
match[2] + // g
|
|
|
|
match[3] +
|
|
|
|
match[3] + // b
|
|
|
|
'ff', // a
|
|
|
|
16,
|
|
|
|
) >>> 0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// https://drafts.csswg.org/css-color-4/#hex-notation
|
|
|
|
if ((match = matchers.hex8.exec(color))) {
|
2016-02-07 21:13:35 +03:00
|
|
|
return parseInt(match[1], 16) >>> 0;
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.hex4.exec(color))) {
|
2018-05-11 05:06:46 +03:00
|
|
|
return (
|
|
|
|
parseInt(
|
|
|
|
match[1] +
|
|
|
|
match[1] + // r
|
|
|
|
match[2] +
|
|
|
|
match[2] + // g
|
|
|
|
match[3] +
|
|
|
|
match[3] + // b
|
|
|
|
match[4] +
|
|
|
|
match[4], // a
|
|
|
|
16,
|
|
|
|
) >>> 0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.hsl.exec(color))) {
|
|
|
|
return (
|
2017-08-18 04:36:54 +03:00
|
|
|
(hslToRgb(
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
parse360(match[1]), // h
|
|
|
|
parsePercentage(match[2]), // s
|
2018-05-11 05:06:46 +03:00
|
|
|
parsePercentage(match[3]), // l
|
|
|
|
) |
|
|
|
|
0x000000ff) >>> // a
|
|
|
|
0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((match = matchers.hsla.exec(color))) {
|
|
|
|
return (
|
2017-08-18 04:36:54 +03:00
|
|
|
(hslToRgb(
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
parse360(match[1]), // h
|
|
|
|
parsePercentage(match[2]), // s
|
2018-05-11 05:06:46 +03:00
|
|
|
parsePercentage(match[3]), // l
|
|
|
|
) |
|
|
|
|
parse1(match[4])) >>> // a
|
|
|
|
0
|
|
|
|
);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
function hue2rgb(p: number, q: number, t: number): number {
|
|
|
|
if (t < 0) {
|
|
|
|
t += 1;
|
|
|
|
}
|
|
|
|
if (t > 1) {
|
|
|
|
t -= 1;
|
|
|
|
}
|
|
|
|
if (t < 1 / 6) {
|
|
|
|
return p + (q - p) * 6 * t;
|
|
|
|
}
|
|
|
|
if (t < 1 / 2) {
|
|
|
|
return q;
|
|
|
|
}
|
|
|
|
if (t < 2 / 3) {
|
|
|
|
return p + (q - p) * (2 / 3 - t) * 6;
|
|
|
|
}
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
function hslToRgb(h: number, s: number, l: number): number {
|
2018-05-11 01:44:52 +03:00
|
|
|
const q = l < 0.5 ? l * (1 + s) : l + s - l * s;
|
|
|
|
const p = 2 * l - q;
|
|
|
|
const r = hue2rgb(p, q, h + 1 / 3);
|
|
|
|
const g = hue2rgb(p, q, h);
|
|
|
|
const b = hue2rgb(p, q, h - 1 / 3);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
|
|
|
|
return (
|
2018-05-11 05:06:46 +03:00
|
|
|
(Math.round(r * 255) << 24) |
|
|
|
|
(Math.round(g * 255) << 16) |
|
|
|
|
(Math.round(b * 255) << 8)
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2016-02-01 09:45:30 +03:00
|
|
|
// var INTEGER = '[-+]?\\d+';
|
2018-05-11 01:44:52 +03:00
|
|
|
const NUMBER = '[-+]?\\d*\\.?\\d+';
|
|
|
|
const PERCENTAGE = NUMBER + '%';
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
|
|
|
|
function call(...args) {
|
|
|
|
return '\\(\\s*(' + args.join(')\\s*,\\s*(') + ')\\s*\\)';
|
|
|
|
}
|
|
|
|
|
2018-06-02 03:48:58 +03:00
|
|
|
let cachedMatchers;
|
|
|
|
|
|
|
|
function getMatchers() {
|
|
|
|
if (cachedMatchers === undefined) {
|
|
|
|
cachedMatchers = {
|
|
|
|
rgb: new RegExp('rgb' + call(NUMBER, NUMBER, NUMBER)),
|
|
|
|
rgba: new RegExp('rgba' + call(NUMBER, NUMBER, NUMBER, NUMBER)),
|
|
|
|
hsl: new RegExp('hsl' + call(NUMBER, PERCENTAGE, PERCENTAGE)),
|
|
|
|
hsla: new RegExp('hsla' + call(NUMBER, PERCENTAGE, PERCENTAGE, NUMBER)),
|
|
|
|
hex3: /^#([0-9a-fA-F]{1})([0-9a-fA-F]{1})([0-9a-fA-F]{1})$/,
|
|
|
|
hex4: /^#([0-9a-fA-F]{1})([0-9a-fA-F]{1})([0-9a-fA-F]{1})([0-9a-fA-F]{1})$/,
|
|
|
|
hex6: /^#([0-9a-fA-F]{6})$/,
|
|
|
|
hex8: /^#([0-9a-fA-F]{8})$/,
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return cachedMatchers;
|
|
|
|
}
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
|
|
|
|
function parse255(str: string): number {
|
2018-05-11 01:44:52 +03:00
|
|
|
const int = parseInt(str, 10);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
if (int < 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (int > 255) {
|
|
|
|
return 255;
|
|
|
|
}
|
|
|
|
return int;
|
|
|
|
}
|
|
|
|
|
|
|
|
function parse360(str: string): number {
|
2018-05-11 01:44:52 +03:00
|
|
|
const int = parseFloat(str);
|
2018-06-06 15:20:40 +03:00
|
|
|
return (((int % 360) + 360) % 360) / 360;
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
function parse1(str: string): number {
|
2018-05-11 01:44:52 +03:00
|
|
|
const num = parseFloat(str);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
if (num < 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (num > 1) {
|
|
|
|
return 255;
|
|
|
|
}
|
|
|
|
return Math.round(num * 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
function parsePercentage(str: string): number {
|
|
|
|
// parseFloat conveniently ignores the final %
|
2018-05-11 01:44:52 +03:00
|
|
|
const int = parseFloat(str);
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
if (int < 0) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (int > 100) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return int / 100;
|
|
|
|
}
|
|
|
|
|
2018-05-11 01:44:52 +03:00
|
|
|
const names = {
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
transparent: 0x00000000,
|
|
|
|
|
|
|
|
// http://www.w3.org/TR/css3-color/#svg-color
|
2016-02-07 21:13:35 +03:00
|
|
|
aliceblue: 0xf0f8ffff,
|
|
|
|
antiquewhite: 0xfaebd7ff,
|
|
|
|
aqua: 0x00ffffff,
|
|
|
|
aquamarine: 0x7fffd4ff,
|
|
|
|
azure: 0xf0ffffff,
|
|
|
|
beige: 0xf5f5dcff,
|
|
|
|
bisque: 0xffe4c4ff,
|
|
|
|
black: 0x000000ff,
|
|
|
|
blanchedalmond: 0xffebcdff,
|
|
|
|
blue: 0x0000ffff,
|
|
|
|
blueviolet: 0x8a2be2ff,
|
|
|
|
brown: 0xa52a2aff,
|
|
|
|
burlywood: 0xdeb887ff,
|
|
|
|
burntsienna: 0xea7e5dff,
|
|
|
|
cadetblue: 0x5f9ea0ff,
|
|
|
|
chartreuse: 0x7fff00ff,
|
|
|
|
chocolate: 0xd2691eff,
|
|
|
|
coral: 0xff7f50ff,
|
|
|
|
cornflowerblue: 0x6495edff,
|
|
|
|
cornsilk: 0xfff8dcff,
|
|
|
|
crimson: 0xdc143cff,
|
|
|
|
cyan: 0x00ffffff,
|
|
|
|
darkblue: 0x00008bff,
|
|
|
|
darkcyan: 0x008b8bff,
|
|
|
|
darkgoldenrod: 0xb8860bff,
|
|
|
|
darkgray: 0xa9a9a9ff,
|
|
|
|
darkgreen: 0x006400ff,
|
|
|
|
darkgrey: 0xa9a9a9ff,
|
|
|
|
darkkhaki: 0xbdb76bff,
|
|
|
|
darkmagenta: 0x8b008bff,
|
|
|
|
darkolivegreen: 0x556b2fff,
|
|
|
|
darkorange: 0xff8c00ff,
|
|
|
|
darkorchid: 0x9932ccff,
|
|
|
|
darkred: 0x8b0000ff,
|
|
|
|
darksalmon: 0xe9967aff,
|
|
|
|
darkseagreen: 0x8fbc8fff,
|
|
|
|
darkslateblue: 0x483d8bff,
|
|
|
|
darkslategray: 0x2f4f4fff,
|
|
|
|
darkslategrey: 0x2f4f4fff,
|
|
|
|
darkturquoise: 0x00ced1ff,
|
|
|
|
darkviolet: 0x9400d3ff,
|
|
|
|
deeppink: 0xff1493ff,
|
|
|
|
deepskyblue: 0x00bfffff,
|
|
|
|
dimgray: 0x696969ff,
|
|
|
|
dimgrey: 0x696969ff,
|
|
|
|
dodgerblue: 0x1e90ffff,
|
|
|
|
firebrick: 0xb22222ff,
|
|
|
|
floralwhite: 0xfffaf0ff,
|
|
|
|
forestgreen: 0x228b22ff,
|
|
|
|
fuchsia: 0xff00ffff,
|
|
|
|
gainsboro: 0xdcdcdcff,
|
|
|
|
ghostwhite: 0xf8f8ffff,
|
|
|
|
gold: 0xffd700ff,
|
|
|
|
goldenrod: 0xdaa520ff,
|
|
|
|
gray: 0x808080ff,
|
|
|
|
green: 0x008000ff,
|
|
|
|
greenyellow: 0xadff2fff,
|
|
|
|
grey: 0x808080ff,
|
|
|
|
honeydew: 0xf0fff0ff,
|
|
|
|
hotpink: 0xff69b4ff,
|
|
|
|
indianred: 0xcd5c5cff,
|
|
|
|
indigo: 0x4b0082ff,
|
|
|
|
ivory: 0xfffff0ff,
|
|
|
|
khaki: 0xf0e68cff,
|
|
|
|
lavender: 0xe6e6faff,
|
|
|
|
lavenderblush: 0xfff0f5ff,
|
|
|
|
lawngreen: 0x7cfc00ff,
|
|
|
|
lemonchiffon: 0xfffacdff,
|
|
|
|
lightblue: 0xadd8e6ff,
|
|
|
|
lightcoral: 0xf08080ff,
|
|
|
|
lightcyan: 0xe0ffffff,
|
|
|
|
lightgoldenrodyellow: 0xfafad2ff,
|
|
|
|
lightgray: 0xd3d3d3ff,
|
|
|
|
lightgreen: 0x90ee90ff,
|
|
|
|
lightgrey: 0xd3d3d3ff,
|
|
|
|
lightpink: 0xffb6c1ff,
|
|
|
|
lightsalmon: 0xffa07aff,
|
|
|
|
lightseagreen: 0x20b2aaff,
|
|
|
|
lightskyblue: 0x87cefaff,
|
|
|
|
lightslategray: 0x778899ff,
|
|
|
|
lightslategrey: 0x778899ff,
|
|
|
|
lightsteelblue: 0xb0c4deff,
|
|
|
|
lightyellow: 0xffffe0ff,
|
|
|
|
lime: 0x00ff00ff,
|
|
|
|
limegreen: 0x32cd32ff,
|
|
|
|
linen: 0xfaf0e6ff,
|
|
|
|
magenta: 0xff00ffff,
|
|
|
|
maroon: 0x800000ff,
|
|
|
|
mediumaquamarine: 0x66cdaaff,
|
|
|
|
mediumblue: 0x0000cdff,
|
|
|
|
mediumorchid: 0xba55d3ff,
|
|
|
|
mediumpurple: 0x9370dbff,
|
|
|
|
mediumseagreen: 0x3cb371ff,
|
|
|
|
mediumslateblue: 0x7b68eeff,
|
|
|
|
mediumspringgreen: 0x00fa9aff,
|
|
|
|
mediumturquoise: 0x48d1ccff,
|
|
|
|
mediumvioletred: 0xc71585ff,
|
|
|
|
midnightblue: 0x191970ff,
|
|
|
|
mintcream: 0xf5fffaff,
|
|
|
|
mistyrose: 0xffe4e1ff,
|
|
|
|
moccasin: 0xffe4b5ff,
|
|
|
|
navajowhite: 0xffdeadff,
|
|
|
|
navy: 0x000080ff,
|
|
|
|
oldlace: 0xfdf5e6ff,
|
|
|
|
olive: 0x808000ff,
|
|
|
|
olivedrab: 0x6b8e23ff,
|
|
|
|
orange: 0xffa500ff,
|
|
|
|
orangered: 0xff4500ff,
|
|
|
|
orchid: 0xda70d6ff,
|
|
|
|
palegoldenrod: 0xeee8aaff,
|
|
|
|
palegreen: 0x98fb98ff,
|
|
|
|
paleturquoise: 0xafeeeeff,
|
|
|
|
palevioletred: 0xdb7093ff,
|
|
|
|
papayawhip: 0xffefd5ff,
|
|
|
|
peachpuff: 0xffdab9ff,
|
|
|
|
peru: 0xcd853fff,
|
|
|
|
pink: 0xffc0cbff,
|
|
|
|
plum: 0xdda0ddff,
|
|
|
|
powderblue: 0xb0e0e6ff,
|
|
|
|
purple: 0x800080ff,
|
|
|
|
rebeccapurple: 0x663399ff,
|
|
|
|
red: 0xff0000ff,
|
|
|
|
rosybrown: 0xbc8f8fff,
|
|
|
|
royalblue: 0x4169e1ff,
|
|
|
|
saddlebrown: 0x8b4513ff,
|
|
|
|
salmon: 0xfa8072ff,
|
|
|
|
sandybrown: 0xf4a460ff,
|
|
|
|
seagreen: 0x2e8b57ff,
|
|
|
|
seashell: 0xfff5eeff,
|
|
|
|
sienna: 0xa0522dff,
|
|
|
|
silver: 0xc0c0c0ff,
|
|
|
|
skyblue: 0x87ceebff,
|
|
|
|
slateblue: 0x6a5acdff,
|
|
|
|
slategray: 0x708090ff,
|
|
|
|
slategrey: 0x708090ff,
|
|
|
|
snow: 0xfffafaff,
|
|
|
|
springgreen: 0x00ff7fff,
|
|
|
|
steelblue: 0x4682b4ff,
|
|
|
|
tan: 0xd2b48cff,
|
|
|
|
teal: 0x008080ff,
|
|
|
|
thistle: 0xd8bfd8ff,
|
|
|
|
tomato: 0xff6347ff,
|
|
|
|
turquoise: 0x40e0d0ff,
|
|
|
|
violet: 0xee82eeff,
|
|
|
|
wheat: 0xf5deb3ff,
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
white: 0xffffffff,
|
2016-02-07 21:13:35 +03:00
|
|
|
whitesmoke: 0xf5f5f5ff,
|
|
|
|
yellow: 0xffff00ff,
|
|
|
|
yellowgreen: 0x9acd32ff,
|
Reimplement color processing
Summary:
**Problem:**
As I was trying to document what color formats we supported, I realized that our current implementation based on the open source project tinycolor supported some crazy things. A few examples that were all valid:
```
tinycolor('abc')
tinycolor(' #abc ')
tinycolor('##abc')
tinycolor('rgb 255 0 0')
tinycolor('RGBA(0, 1, 2)')
tinycolor('rgb (0, 1, 2)')
tinycolor('hsv(0, 1, 2)')
tinycolor({r: 10, g: 10, b: 10})
tinycolor('hsl(1%, 2, 3)')
tinycolor('rgb(1.0, 2.0, 3.0)')
tinycolor('rgb(1%, 2%, 3%)')
```
The integrations of tinycolor were also really bad. processColor added "support" for pure numbers and an array of colors!?? ColorPropTypes did some crazy trim().toString() and repeated a bad error message twice.
**Solution:**
While iteratively cleaning the file, I eventually ended up reimplementing it entierly. Major changes are:
- The API is now dead simple: returns null if it doesn't parse or returns the int32 representation of the color
- Stricter parsing of at
Closes https://github.com/facebook/react-native/pull/5529
Reviewed By: svcscm
Differential Revision: D2872015
Pulled By: nicklockwood
fb-gh-sync-id: df78244eefce6cf8e8ed2ea51f58d6b232de16f9
2016-01-29 20:11:53 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
module.exports = normalizeColor;
|