Feature/issue 87 jsx coarse grained observability

[thescientist13]

Related Issue

resolves #87

Summary of Changes

1. Scan render and constructor functions for usages of this to generate observedAttributes and attributeChangedCallback
2. Made it optional through being able to export const inferredObservability = {boolean}

For example, this

export default class Greeting extends HTMLElement {
  constructor() {
    this.name = '';
  }
  
  render() {
   const { name = 'World' } = this;
 
   return (
     <h1>Hello ${name}!</h1>  
  }
}

customElements.define('my-greeting', Greeting);

Would produce this

export default class Greeting extends HTMLElement {
  static get observedAttributes() {
    return ['name'];
  }

  constructor() {
    this.name = '';
  }
  
  render() {
   const { name = 'World' } = this;
 
   this.innerHTML = `<h1>Hello ${name}!</h1>`;
  }
}

customElements.define('my-greeting', Greeting);

Use it as

<my-greeting name="WCC"></my-greeting>

Very simple implementation right now mostly as a nice way to do basic text updates / substations, as can be seen in thescientist13/greenwood-counter-jsx#3

A more complex approach aiming for more fine grained reactivity, like for lists, would be conducted in a second PR and can be followed along with here thescientist13/todo-app#3

TODOs

1. Tests
2. Try and get an example of attributeChangedCallback with fine grained observability
3. Custom export to opt-in / out
4. Refine observability detection algorithm (or track as known issues with concrete examples) for "derived" this state - all being tracked in Literal this Evaluation and Derivative References #88
5. Documentation
   • Add more examples / links to examples
   • Add caveats
   • Optionality (inferObservability)
   • mapping props to attrs
6. Clean up console logs / commented out code

Questions / Observations (follow up issues / discussions)

1. Currently this assumes attributes map to properties. Need to distinguish the two? Or just document that we "auto" reflect by default? - documented as such for now
2. Do we need to get hints / signals of all members in render function up front before we parse and / or add instruction sets? - yes, I think we do this now
3. Would be nice if there was a way to "stringify" the function code for better syntax highlighting - will track in our backlog
4. Do we need to match in both render and constructor? Or just infer from render() only? - Will just use render function for now
5. Check if observedAttributes or attributeChangedCallback exists, and merge? Or defer to what already exists? Explicit Opt-in / out?
6. Might be nice to have E2E tests for testing interactivity of generated code in a browser - will track in our backlog