How to implement shouldUpdate?

[kevkov]

I'm going through the lit.dev tutorials and converting them to Fable (Lit.Samples.Fable) and it is fun. However, in Reactivity 4 the shouldUpdate method is used but this is not available on LitElement. Until it is available I guess I could add it as a type extension? The TS signature is shouldUpdate(changedProperties: PropertyValues<this>): boolean. How would this look in F#/Fable? Any help appreciated.

[AngelMunoz]

At the moment I don't think we have any of the life cycle methods available for overload,
What we do is that we wrap the function decorated with either HookComponent or LitElement in a directive/class that handles these updates under the hood, but that also means same of the mechanisms are hidden like connectedCallback and disconnectedCallback as well, there are some hooks that can help but you are not really accessing those or overriding them

I think if you need these or accessing to the class based API an issue should be opened

[kevkov]

Thanks. Realised shortly after that this was a bit of daft question as exposing the class API is not really the focus of Fable.Lit. And I wont be raising an issue until I have better use case than doing the Lit tutorials :)

[alfonsogarciacaro]

I guess that either we have to provide a way to declare Lit elements with classes (and solve the issue with Typescript decorators that currently Fable cannot generate) or just add more options to the init configuration so methods like shouldUpdate are mounted in the generated class.

[AngelMunoz]

@alfonsogarciacaro I think one of the simplest things we could do as well, would be to just expose the class API, the things that can be used with decorators are normally exposed as static properties e.g.

If there's people coming from lit it wouldn't be to different from this

// not sure why I couldn't find this in Fable.Core.Constructors
[<Emit("Boolean")>]
let BoolCtr: obj = jsNative

[<AttachMembers>]
type MyCounter() =
  inherit LitElement()
  // val members get getters and setters
  // and that doesn't work fine with Lit's reactive mechanism
  // let mutables do work though but could be a problem with interop
  // if we want to access properties from elements made with F#
  let mutable enabled: bool = false
  let mutable count: int = 0

  static member styles =
    [| css $":host {{ display: flex; }}" |]
  // we could try to come up with a more ergonomic way to define these
  // but ultimately this has to be a plain JS object
  static member properties = {|
    enabled = {| ``type`` = BoolCtr; attribute = true |}
    count = {| ``type`` = Constructors.Number; state = true |}
  |}

  override member _.connectedCallback() =
    printfn "Connected"

  member this.render() =
      html 
          $"""
          <button 
            @click={fun _ -> count <- count + 1}
            ?disabled={enabled}>
            Count: {count}
          </button>
          <button @click={fun _ -> enabled <- (not enabled)}>Toggle Counter</button>"""

to this

class MyCounter extends LitElement {
  static get styles() { return [css`:host { display: flex; }`] }
  static get properties() {
    return { 
     enabled: { type: Boolean, attribute: true }
     count: { type: Number, state: true }
    };
  }
  
  constructor() {
    this.counter = 0;
    this.enabled = true;
  }

  connectedCallback() { console.log("connected") }

  render() {
    html`
     <button 
       @click={fun _ -> this.count = this.count + 1}
       ?disabled={this.enabled}>
       Count: {this.count}
     </button>
     <button @click={fun _ -> this.enabled = !this.enabled}>Toggle Counter</button>
   `;
  }
}

I get this is not the most F# friendly way but these are still safer than plain Javascript and could actually play good with Reactive Controllers (although function based elements work nicely on your PR branch)

I wanted to dive into this but hadn't had a chance, I would also like to have this 1-1 style of bindings with a some sort of guide on when/what/why to use classes vs function lit elements

[alfonsogarciacaro]

@AngelMunoz Makes sense! So users can just follow Lit documentation. Only thing is having to duplicate the properties is not very nice. I wonder if we could use the decorators in a similar fashion they do it in the Typescript version.

[AngelMunoz]

I'm not too happy with that either but at least it is what people would do with plain JavaScript as well so it doesn't go too far from the rails

one thing to consider is that the decorators proposal advanced to stage-3 so it will be implemented in browsers at some point https://github.com/tc39/proposal-decorators so we might want to look at that as well I'm pretty sure lit will want to leverage that as well at some point

[alfonsogarciacaro]

Another thing to consider is that HMR support is possible thanks to the render function being exposed as a module function. If I remember correctly, HMR doesn't work with Lit class components.

[alfonsogarciacaro]

Also, I just remember Prop.Of has a hasChanged optional parameter that you can use to decide if the component should re-render when the property value is updated:

Fable.Lit/src/Lit/LitElement.fs

Lines 90 to 94 in 4560f60

	static member Of
	(
	defaultValue: 'T,
	?attribute: string,
	?hasChanged: 'T -> 'T -> bool,