Deprecate the use of deep lists when composing styles in favor of the Spread syntax

[UpperCod]

In Atomico 1.31.0 the compatibility with deep list composition exploration of style was announced, this in order to have an aesthetic similar to the use of children.

This was an early feature and I leave the space to discuss the disconuity of this feature.

1.31.0

const style1 = css`:host{}`;
const style2 = [style1, css`:host{}` ];

function component(){
    return <host></host>;
}

component.styles = [
    style2,
    css`:host{...}`
]

before 1.31.0

const style1 = css`:host{}`;
const style2 = [style1, css`:host{}` ];

function component(){
    return <host></host>;
}

component.styles = [
   ...style2, // 👈 Spread syntax 
   css`:host{...}`
]

cost without compression

151bytes aprox

before

//fragment 1
return [super.styles||[],styles||[]]
//fragment 2
styles = new Set(...styles);

1.31.0

//fragment 1
return [super.styles,styles]
//fragment 2
styles = styles.reduce(function concat(styles, style) {
      isArray(style)
          ? style.reduce(concat, styles)
          : style && styles.push(style);
      return styles;
}, []);

[Explosion-Scratch]

Why are you doing the weird reduce stuff, just do styles.flat(1000)

[UpperCod]

The reality is that it did not know the first parameter for [].flat and in my mind reduce responded to the analysis of empty and lists before inserting ... Now comparing there are differences in performance:

3,229 ops / s flat
17,739 ops / s reduces

.... Performance or Simplicity? that's the dilemma

By the way I do not rule out the solution with .flat, it would be good to use it eliminating the empty condition

[Explosion-Scratch]

Still, you're not going to be flattening huge lists, right? Theoretically these are going to be small, and atomico advertises being small, so using .flat supports that ideology 😐 Ultimately it's a small issue and up to you as the developer, just my thoughts! 😃