[lexical] Fix flow error: change this to any

[potatowagon]

Seems that flow isnt able to compile this type as an input param type: see sample
error

This results in downstream errors such as this scenerio:

export class QuoteLineNode extends TextNode {

  updateDOM(
    prevNode: TextNode,
    dom: HTMLElement,
    config: EditorConfig,
  ): boolean {
    // errors here
    const shouldUpdate = super.updateDOM(prevNode, dom, config);
    return shouldUpdate;
  }
}

In this example, super is a TextNode, and prevNode, being this typed, should be a TextNode, but flow isnt able to determine that. The error:

Cannot call super.updateDOM with prevNode bound to prevNode because TextNode [1]
is incompatible with this [2]. [incompatible-call]

In this PR, changing this to any as a quick fix for the flow apis. Will look into adding stricter typing for each node's updateDom in future PRs, refer to https://github.com/facebook/lexical/pull/6894/files for possible places

I also tried changing the flow api to updateDOM(prevNode: LexicalNode, ... but that resulted in errors everywhere as flow isnt able to eg. tell that a ParagraphNode is a LexicalNode, strangely.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 23, 2024 5:55pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 23, 2024 5:55pm

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	31.31 KB (0%)
lexical - esm	31.13 KB (0%)
@lexical/rich-text - cjs	40.32 KB (0%)
@lexical/rich-text - esm	32.99 KB (0%)
@lexical/plain-text - cjs	38.87 KB (0%)
@lexical/plain-text - esm	30.24 KB (0%)
@lexical/react - cjs	42.12 KB (0%)
@lexical/react - esm	34.27 KB (0%)

[zurfyx]

I wonder if we should explore the generics route we're using for other functions, or just use FlowFixMe in product code like we're using already for other methods

[etrepum]

In this case the downstream code's type annotation is wrong, up to you whether you put FlowFixMe here to work around the wrong annotation in downstream code or not. It doesn't affect any OSS users because almost nobody uses flow outside of Meta.

export class QuoteLineNode extends TextNode {

  updateDOM(
    prevNode: TextNode,
    dom: HTMLElement,
    config: EditorConfig,
  ): boolean {
    // errors here
    const shouldUpdate = super.updateDOM(prevNode, dom, config);
    return shouldUpdate;
  }
}

Should be:

export class QuoteLineNode extends TextNode {

  updateDOM(
    prevNode: this,
    dom: HTMLElement,
    config: EditorConfig,
  ): boolean {
    // errors here
    const shouldUpdate = super.updateDOM(prevNode, dom, config);
    return shouldUpdate;
  }
}

[etrepum]

Specifically updateDOM is always called with another instance of the exact same class (prevNode.constructor === this.constructor). The TextNode annotation in the downstream code only worked because there wasn't any code that needed to inspect anything that isn't in the base class other than calling the super implementation, so it passed the type checker but it was never really correct.

[potatowagon]

thanks for looking into this, changing to updateDOM(prevNode: this,... in QuoteLineNode threw the

prevNode: this,
^ Cannot use this [1] in an input position because this [1] is expected to occur only in output positions. [incompatible-variance]

same as sample error linked in the description

[etrepum]

That might be a problem with Flow then, it might not be able to represent this constraint. Possibly always specifying the exact class that is overriding the method will work? Or maybe there is another Flow specific trick that can be used here? Last time I used Flow it was very different.