Why isn't the destroy() method documented?

[arcanemachine]

I was doing a little bit of poking around at https://component-party.dev/, and it gave an example using Alpine.JS that uses a destroy() method in x-data.

I hadn't heard of this method, so I took a look around the docs, and it's not there. Then, I did a bit of searching and came upon this blog post from nearly two years ago, describing this same destroy() method, although it explicitly mentions that it's undocumented and it should be used with caution.

So what's the story on this method? Should I use it or should I avoid it? Should it be added to the docs?

[ekwoka]

Generally, the reason things are left undocumented is so that they could be changed (in behavior, name, etc) without needing a major version release.

It's possible that, for a period, Caleb had other plans for it, or may still have them, and hasn't committed to this.

He has mentioned liking how useEffect in React lets you return a cleanup function, and that maybe Alpine.effect and init could do something similar.

But we can only really guess.

But yes, the reason anything would be undocumented is normally to prevent people from writing code that depends on something that could breakingly change.

You can try to make that PR and see what happens.

[arcanemachine]

@calebporzio Any thoughts? Is this feature safe to use?

[stepanjakl]

I might have an interesting use-case for this feature. I have combined the usage of Alpine.js and Barba.js for transitioning between pages. The issue I am facing is that once a component is initialized through the alpine:init event, its listener stays active even after the page changes. When another alpine:init event is triggered during page change, that component is no longer available in the DOM. I am looking for the best way to either initialize components individually or effectively remove the event listener. Could the destroy() method be the answer to this problem?

EDIT: Componets do get destroyed on page change - destroyed() is simply a lifecycle hook, however the alpine:init that's binded to the document object still remains there.

[ekwoka]

You should not be reinitializing Alpine during the content swap.

Alpine will continue to run and hook into all the new components in the new content.