Lwc: Exposing Node.prototype.isConnected on LightningElement

Created on 27 Jan 2020  路  5Comments  路  Source: salesforce/lwc

Is your feature request related to a problem? Please describe.

From Chuck Liddell:

What is the equivalent of component.isValid() in LWC-world? For example, I have a server call that is returning after the LWC is no longer showing to the user, and I don't want to process that response, yet I can see in console that not only is it processing there seems to be no issue calling the server again and again from that (now-hidden) component.

Original thread: link

Describe the solution you'd like

From @aheber:

I haven鈥檛 tried it yet but does this help at all?
https://developer.mozilla.org/en-US/docs/Web/API/Node/isConnected

Developers expect Node.prototype.isConnected to be exposed on the component instance, but it is not the case today. The current way to know if the component is connected or not is the value via: this.template.host.isConnected.

BUG P3

Most helpful comment

Yes, it's an ergonomic improvement to avoid some boilerplate code.

All 5 comments

The history about this, in the past, we didn't have a polyfill for it (missing in IE11), now we do.
Additionally,this.isConnected is considered useless if you're relying on the platform pieces that we offer (only useful if you're doing your own thing, e.g.: in OSS).

I believe we can enable it, but with one condition, add a dev-time check that if this value is accessed during rendering or construction, give them an error, because that means it is unnecessary check during the critical path. In construction path, it is always false, in rendering path, it is always true otherwise it will not have being rendered.

I believe we can enable it, but with one condition, add a dev-time check that if this value is accessed during rendering or construction [...]

Sounds good to me.

I have a server call that is returning after the LWC is no longer showing to the user, and I don't want to process that response,

connectedCallback() and disconnectedCallback() Can be used to achieve this. What is isConnected providing in addition? Ergonomics maybe, single property look up v/s managing the connectedness in the callbacks.

Note: My argument is not against opening up isConnected.

Yes, it's an ergonomic improvement to avoid some boilerplate code.

This issue has been linked to a new work item: W-7199523

Was this page helpful?
0 / 5 - 0 ratings