attr typecasting

[bcardarella]

In class rules the attr values are string, we should allow for typecasting:

foregroundStyle(Color(red: attr("red", :float), green: attr("green", :float), blue: attr("blue", :float))

results in:

{:foregroundStyle, [], [{:Color, [], [red: {:__attr__, [], ["red", :float]}, green: {:__attr__, [], ["green", :float]}, blue: {:__attr__, [], ["blue", :float]}]}

[carson-katri]

I don't believe this is necessary, as the client automatically decodes to the correct type based on the modifier's arguments.

However, CSS does support this with slightly different syntax. From MDN:

/* Simple usage */
attr(data-count);
attr(title);

/* With type */
attr(src url);
attr(data-count number);
attr(data-width px);

/* With fallback */
attr(data-count number, 0);
attr(src url, "");
attr(data-width px, inherit);
attr(data-something, "default");

[bcardarella]

In this case the Color modifier was not accepted text representations of a float. I tried:

foregroundStyle(Color(red: attr("red"), green: attr("green"), blue: attr("blue")))

with:

<Rectangle red="0.5" green="0.1" blue="0.7" />

with no luck until I changed to the more explicit float:

foregroundStyle(Color(red: 0.5, green: 0.1, blue: 0.7))

[carson-katri]

That's an issue with Color not accepting attribute value numbers. It needs to have AttributeDecodable added to its red, green, and blue arguments, then make the Color itself attribute decodable so it can pass the element through.

[bcardarella]

@carson-katri ah ok, out of curiosity is there a way to determine which other views within the client would require AttributeDecodable or do we have to add as we go?

[carson-katri]

There's a list in the modifier generator. In this case, Color is already attribute decodable, it just needs to extend that to its arguments

https://github.com/liveview-native/liveview-client-swiftui/blob/a636966a05f8e5a7782171c578244b40946749b2/Sources/ModifierGenerator/Signature.swift#L281-L299