# Pattern: NaiveStyleCallback

The NaiveStyleCallback pattern adds a lifecycle callback to the web component:
`styleCallback(...)`.
The NaiveStyleCallback first observes when a `.style` property on the host element has changed
and then trigger `styleCallback(cssPropertyName, newValue, oldValue)` with the property name, 
new value and old value as arguments, very much like the `attributeChangedCallback(...)`.

## Why `styleCallback(...)`?

The role of `styleCallback(...)` is to:
1. observe the CSS properties (and their changes) on the host element in the lightDOM and then
2. trigger a JS function that can react to these changes.

Again, this clearly echoes how the `attributeChangedCallback(...)` observes and reacts to HTML
attribute changes. So, why do we need to do the same with CSS properties? Why not just specify property
as an HTML attribute instead?

First, from the viewpoint of the individual web component, there is *no* reason why we cannot use 
`attributeChangedCallback(...)` instead. If all you have to consider is the current web component, 
then the answer is likely to be *not* to use observe CSS properties and with a `styleCallback(...)`, 
but instead *cast* the style property in question as an HTML attribute.

However, the individual web component does not *decide* where an app should specify its style properties.
Most often, properties such as `color` and `border` are set in CSS, and there is little the web 
component can do to change that. If the web component needs to know its `color`, `border` or other 
properties, its not really an option for it to say that "you should have specified that as an HTML 
attribute instead".

Second, as described before, both HTML attributes and CSS classes has to be assigned an element either
statically from HTML template or dynamically from JS. CSS properties on the other hand can be assigned
to an element *from CSS rules*, both statically and dynamically. All the reasons to use CSS selectors
and CSS properties instead of HTML attributes to prescribe style to DOM elements in essence apply
to coordinating the inner style of web components. There is essentially *no* conceptual difference 
between applying an established CSS properties such as the generic `color` or the element specific 
`border-collapse` and a custom property your web component needs to observe and react to in order to
implement and calculate its inner style and structure.

Third, currently, HTML attributes are used to control most aspects of a web components inner state.
If you need to be able to control the web components state and behavior from both HTML and JS, 
then HTML attributes is more or less your only means (if we here disregard the more complex option of
slotting specialized elements). On the web component you would need to set one set of HTML attributes
to control its content structure, another set of HTML attributes to control its imperative behavior (JS)
and a third set of HTML attributes to coordinate its style. Splitting out control of an element's style
as custom CSS properties not only enables CSS rules and developers to control it, but also in a sense
relieves the HTML template and developer of this task.

## A naive implementation of `styleCallback(...)` 

Basically, the `styleCallback(...)` needs to observe some styles on the host element.
To get the current CSS properties of an element we have to use the `getComputedStyle(el)` method.
Then, we need to check if the relevant CSS property has changed on the element, and 
if so we need to trigger the `styleCallback(cssPropertyName, newValue, oldValue)` 
with the property name, new value and old value as arguments.

Each web component does not need to observe *all* its CSS properties.
Therefore, the NaiveStyleCallback pattern uses the StaticSetting pattern to specify 
which CSS properties it should observe. We call this method `observedStyles()`:
```
static get observedStyles(){
  return ["font-size", "--custom-color-prop"];
}
```
Note: Due to restrictions in the [CSSStyleDeclaration](https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration)
object, you can only observe:
1. established CSS properties such as `color` and `border` and
2. CSS variables such as `--custom-css-prop`.

In the browser, there is no native callback for changes to the CSSOM. This means that the 
`styleCallback(...)` itself must poll the CSSOM to check if the properties have changed.
This "polling the CSSOM to trigger a JS callback" is problematic, as will be described in the next 
chapter. However, in this first, naive implementation of `styleCallback(...)` we simply assume
that this polling and subsequent JS callback will not cause any conflicts, and just schedule a the
poll using `requestAnimationFrame(...)`.

## Demo: `<blue-blue>` with custom `color` CSS properties

In this example we want to add a custom calculation of `<blue-blue>`s color 
using the `color` CSS property and `styleCallback(...)`.

```html
<script>
  class BlueBlue extends HTMLElement {
    constructor() {
      super();
      this.attachShadow({mode: "open"});
      this.shadowRoot.innerHTML = `
       <style>
         div#core {                             
           background-color: var(--light-color, lightblue);              
           color: var(--dark-color, darkblue);          
         }
       </style>
       <div id="core">
         <slot></slot>
       </div>`;                                                      
      this._rafID;
      this._previousStyleValues = {};
      for (let style of this.constructor.observedStyles())
        this._previousStyleValues[style] = undefined;
    }
    
    pollStyle(){
      const newStyles = getComputedStyle(this);
      for (let prop of Object.getKeys(this._oldStyleValues)) {
        let newValue = newStyles.getPropertyValue(prop);
        let oldValue = this._oldStyleValues[prop];
        if (newValue !== oldValue){
          this.styleCallback(prop, oldValue, newValue);
          this._oldStyleValues[prop] = newValue;          
        }
      }
    }
    
    connectedCallback(){
      this._rafID = requestAnimationFrame(this.pollStyle.bind(this));
    }
    
    disconnectedCallback(){
      cancelAnimationFrame(this._rafID);
    }
    
    static get observedStyles(){
      return ["color"];
    }
    
    styleCallback(name, oldValue, newValue){
      if (name === "color"){
        const div = this.shadowRoot.children[1];
        if (newValue) {
          div.style.setProperty("--light-color", "light" + newValue);
          div.style.setProperty("--dark-color", "dark" + newValue);
        } else {
          div.style.setProperty("--light-color", undefined);
          div.style.setProperty("--dark-color", undefined);
        }
      }
    }
  }

  customElements.define("blue-blue", BlueBlue);
</script>

<style>
#one {
  color: green;
}
</style>

<blue-blue id="one">green</blue-blue>            <!--[3]-->
<blue-blue id="two">still blue</blue-blue>

<script>
setTimeout(function(){
  const two = document.querySelector("blue-blue#two");
  two.style.color = "red";
  two.innerText = "blue becomes red";
}, 3000);
</script>
```

Next we will look at how to implement the NaiveStyleCallback as a mixin: NaiveStyleCallbackMixin.
We will also start to look more in depth of the problems of polling CSSOM.

## References

 *