Summary:
The hex8 specified version is #rrggbbaa so it would be great to have the internal representation be 0xrrggbbaa to prevent confusion.
This pull request changes the internals of normalizeColor. It changes a lot of lines but there isn't any big changes.
Small changes:
- Use | instead of + for number operations
- Use x << 24 instead of x * (1 << 24)
- Have hslToRgb return pre shifted number
processColor is still sending colors the 0xaarrggbb format to native and tests still pass without changes.
Closes https://github.com/facebook/react-native/pull/5792
Reviewed By: svcscm
Differential Revision: D2910589
Pulled By: vjeux
fb-gh-sync-id: 6dd353f2edd5127f1762e7a57a65379d2a58e0c1
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
Christopher Chedeau
Justas Brazauskas
Pieter De Baets
Krzysztof Magiera
Alexsander Akers