Extract StyleSetters (eg. for colors) into traits and mix them into revelant objects

[fdietze]

The StyleSetters for the css attribute color are also relevant for other css attributes accepting the color property like background-color, border-color, box-shadow, outline-color, text-shadow.

I think code sharing makes sense here.

scala-dom-types/shared/src/main/scala/com/raquo/domtypes/generic/defs/styles/Styles.scala

Line 505 in 06dab59

lazy val black: StyleSetter = buildStringStyleSetter(this, "black")

(I'm writing down ideas I have while porting a project to the current outwatch PR.)

[raquo]

Agreed.

However, I would like to evaluate other options of dealing with styles before spending too much time polishing the current setup. What we have now I inherited from ScalaTags, and I haven't given it much thought yet.

For one thing, I don't like that we're extending the Style class, feels like it should not be required, that styles should work similar to attrs and props.

I'm thinking maybe to rewrite the styles as e.g.

lazy val backgroundColor: S[CSSColor] = style("color")

where

trait CSSColor { val str: String }
object Red extends CSSColor { override val str: String = "red"}
object Black extends CSSColor { override val str: String = "black"}

With desired usage like this:

div(backgroundColor := Red)

Were we to adopt this kind of API, my biggest concern is discoverability of available values. I gotta check how helpful would IntelliJ be in this scenario.

[raquo]

Alternatively, with a different set of tradeoffs:

lazy val backgroundColor: S[Color] = style(name = "color")

// ------

class Color(val colorStr: String) {
  override def toString(): colorStr // this method will be used to get raw CSS value
}

object Color {
  def apply(colorStr: String): new Color(colorStr) // maybe memoize this function

  lazy val red: new Color("red")
  lazy val black: new Color("black")
}

// -------

backgroundColor := Color("#fff")
backgroundColor := Color.red

[fdietze]

Interesting! This would allow for implicits for different color-libraries.

And in the worst case one could even provide an implicit from String to Color.

[raquo]

Note: This is also relevant to SVG attributes, they have exact same typing problems as CSS properties.

[fdietze]

I'm wondering if we can borrow anything from ScalaCSS.

https://github.com/japgolly/scalacss/blob/7fca2dafd93e017f64a34ea61e3a7290767daf45/core/shared/src/main/scala/scalacss/internal/Values.scala

[raquo]

Yeah, I'll need to look at how ScalaCSS organizes its types. One of the reasons I'm not delegating the entirety of SDT's CSS business to ScalaCSS is that it's apparently quite bulky in terms of bundle size (low hundreds of KBs in fullopt for 200LoC of CSS, as alleged here: http://scalapro.net/scalacss-is-it-time-for-using-it/). I'm hoping all that size is coming not from the Value/ValueT traits but from all the other irrelevant-to-us machinery required for style generation.

[raquo]

I think I might actually get this done. Kinda need it for raquo/Laminar#95.

Looking into it now. So far it looks like the style props will look like val color: SP[String] with ColorStyle[Setter[String]] = colorStyle("color") where both SP ("style prop") and Setter are abstract types, and ColorStyle is a trait that looks a lot like the current object color's type does. Then in the consuming library you'd need to implement the colorStyle builder (well, a bunch of them for all the specialized types), returning concrete instances of Style or its library-specific replacement (similar to how Attrs and Props are done, but a lot more specialized builders).

This pattern removes any instantiation of the Style class from Scala DOM Types, abstracting away that type in a similar manner to how Attrs and Props are organized. This also does not require crazy numbers of generic params for the Styles trait, just a couple.