feat(whiskers): add colors object in context

[nekowinston]

I saw catppuccin/go#10 and was kinda surprised that we overlooked iterating colors, again.

This shortens the whole go lib template to:

package catppuccingo

type {{flavor}} struct{}

// {{titlecase flavor}} flavour variant.
var {{titlecase flavor}} Flavour = {{flavor}}{}

func ({{flavor}}) Name() string { return "{{flavor}}" }

{{ #each colors as | color colorName | }}
func ({{@root/flavor}}) {{titlecase colorName}}() Color {
	return Color{
		Hex: "#{{ color }}",
		RGB: [3]uint32{ {{ red_i color }}, {{ green_i color }}, {{ blue_i color }}},
		HSL: [3]float32{ {{ hsl color }}},
	}
}

{{/each}}

[jolheiser]

This would be fantastic, along with the HSL changes I mentioned in Discord in a separate PR.

[nekowinston]

This would probably be a good time to use the new standardized palette format that I talked to @backwardspy about;
e.g. iterating over accents would be doable now via:

    let accent_names = ["rosewater", ..., "lavender"];
    context["colors"] = colors
        .into_fields_iter()
        .map(|(name, c)| {
            (
                name.to_string(),
                json!({
                    "hex": c.hex().to_ascii_lowercase(),
                    "isAccent": accent_names.contains(&name),
                }),
            )
        })
        .collect();

which could be used like

{{#each colors}}
{{#if this.accent}}
func ({{../flavor}}) {{titlecase @key}}() Color {
	return Color{
		Hex: "#{{this.hex}}",
		RGB: [3]uint32{ {{red_i this.hex}}, {{green_i this.hex}}, {{blue_i this.hex}}},
		HSL: [3]float32{ {{hsl this.hex}}},
	}
}

{{/if}}
{{/each}}

The use case for ports would be {{#each colors}} {{#if this.accent}} {{/if}} {{/each}}, and for passing down the isAccent info to libraries.

This would be fantastic, along with the HSL changes I mentioned in Discord in a separate PR.

After a second look, I'm actually not a fan of using functions to generate the colors, I think it'd be better if all the colors came from our color definitions first.
E.g. {{color.hex}} over {{color}}, {{color.rgb}} over {{rgb color}}.
When you use colormath functions, we can always access the underlying hex/hsl/(whatever is needed) value from the color object, so {{darken color.hex}} would still work.

tinycolor2 works like this, it carries the original inputs until the string is rendered:

$ deno
Deno 1.37.1
> import tinycolor from "https://esm.sh/tinycolor2"
undefined
> tinycolor("#000")
{
  _originalInput: "#000",
  _r: 0,
  _g: 0,
  _b: 0,
  _a: 1,
  _roundA: 1,
  _format: "hex",
  _gradientType: undefined,
  _ok: true
}

[backwardspy]

After a second look, I'm actually not a fan of using functions to generate the colors, I think it'd be better if all the colors came from our color definitions first. E.g. {{color.hex}} over {{color}}, {{color.rgb}} over {{rgb color}}. When you use colormath functions, we can always access the underlying hex/hsl/(whatever is needed) value from the color object, so {{darken color.hex}} would still work.

@nekowinston that's actually how whiskers worked originally, but i hit several issues passing full objects around the handlebars context, specifically when accepting them as arguments to the helper macros. after fixing that (by not using the helper macro), i ran into another issue with (darken red 10).hsl not being valid syntax. i ultimately settled on darken red.hsl 10, as you've suggested, but that meant every helper had to be able to parse every supported colour format (because they receive the hsl string, not the full colour object, and use the successful parser as the helper's output format. as far as i can tell there is no way to separate what the helpers receive as their arguments and what would be rendered into the final output.

that's why it's now colours-as-hexcodes with helper functions to convert them into other formats, because things like hsl (darken red 10) do work, the helpers only ever have to input & output hex codes, and the code is quite significantly simpler than the previous solution.

if you know of a way to make that all work with rich colour objects, i would certainly be interested in seeing it. the theory is nice, i just could not make it work well.

[backwardspy]

that aside, this pr looks great. thanks, like you i'm not sure how we missed this off as a feature again!

[nekowinston]

ran into another issue with (darken red 10).hsl not being valid syntax.

  {{ lookup (darken colors.pink 10) "hex" }}

would work, using subexpressions, but I'm not sure if I'm a fan of that. 🤔

Another option would be having an optional paramter, e.g

  {{ darken colors.pink 10 "rgb" }}

Quick Gist in Deno https://gist.github.com/nekowinston/c3626cce3ad72eb84718cf74393e8e87

---

sorry if this is totally out of scope for this PR, I should probably create a new issue 😅

[backwardspy]

sounds good, let's play with some designs on a dedicated issue and i'll approve this PR