Closed uguraslan closed 6 months ago
I have verified the PR and here are the observations:
The template parser is returning template objects with normalised color codes/values. Before the value is '#44037a' After the conversion value is '0x44037aff'
Here is the coverage for before this fix and after this fix
S.No | Code | Before Fix | After Fix |
---|---|---|---|
1 | lib/templateparser | 94.16 | 100 |
2 | lib/setup | 39.11 | 40.04 |
3 | lib/reactivity | 34.67 | 34.67 |
4 | /lib/colors | 97.89 | 100 |
5 | lib/codegenerator | 100 | 100 |
6 | lib | 70.09 | 70.09 |
7 | components | 34.22 | 34.22 |
8 | source | 36.66 | 35.46 |
9 | announcer | 55.42 | 55.42 |
S.No | Desc | Total Tests | Tests Passed | Tests Failed | Comments |
---|---|---|---|---|---|
1 | Before | 218 | 188 | 30 | |
2 | After | 239 | 238 | 1 | Generate code for a template with a simple for-loop on an Element with a key attribute |
colors.normalize()
method with very strict checks for possible color code/values.defaultColor
) tocolors.normalize()
, which is used by the template parser.color
,:color
,:effects
,effects
. (fixes #68 )color.normalize()
always returns a string unless the optionaldefaultColor
is set to something likenull
. If numeric values for colors are needed, it should be done at later stages after color values are normalised as strings.colors
library have been updated.Example:
The template parser outputs an object. But to visualise how it process colors, the following can be considered the equivalent of the template above after the template parser processes color values: