feat: update rule no-unsupported-ssr-properties to reflect SSR best practices @W-14387292

[seckardt]

No description provided.

[divmain]

Generally LGTM. I did have a couple of questions, and I'd like an answer to the optional call expression nuance.

[divmain]

I would have thought this would need to be this.querySelector?.('span')?.foo?.(). But it seems that the optional chaining operator right before the parenthesis are not always required. The language rules around this are a little opaque to me, and I'd like to ensure we're pointing folks in the right direction with this guidance.

Here's a demonstration of what I'm talking about:

> const a = {}
undefined
> a?.foo?.bar()
undefined
> a?.foo?.bar?.()
undefined
> a.foo = {};
{}
> a?.foo?.bar()
Uncaught TypeError: a?.foo?.bar is not a function
> a?.foo?.bar?.()
undefined

That TypeError is concerning. It seems like if this.querySelector?.('span') returns an element, but that element doesn't have a foo function, this.querySelector?.('span')?.foo() will cause a TypeError to be thrown, which is probably not what we want.

[seckardt]

@divmain Yeah, looking at the runtime code you pointed me to, it seems like the well-intentioned, but problematic "polyfill" behavior in the runtime implements/provides methods like querySelector, yet lets them throw an error when called?! That's pretty unfortunate, as due to that behavior the linting rule to catch all posible issues in that area will have to be much more complex and needs to be more contextual to cover forcing the whole statement to either be guarded or fully be made optional, e.g. a?.foo?.bar?.().

[divmain]

Looks great!