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.
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
Most helpful comment
Yes, it's an ergonomic improvement to avoid some boilerplate code.