Adding injectMagics and initInterceptor to the public API

[anulax1225]

As stayted in (Extending)[https://alpinejs.dev/advanced/extending] setion of the documentation, almost every alpine features should be reproducable by the end user.

But i found it difficulte to reproduce the (x-data)[https://github.com/alpinejs/alpine/blob/main/packages/alpinejs/src/directives/x-data.js] functionnalities. In my case, altought alpine gives every thing i need for procedural tree building with ìnitTree and addScopeToNode, i don't have good control over the data i want to the node.

Example

The classic way :

<button x-data="{
    init: () => {
         //use any magic you want
    }
}">
...
</button>

But if i don't want/can't pass this object trought the x-data directive, i won't get magic injections.

I'm not sure what initInterceptors is neccesary for or for what functionnalities i would need it. But if it's useful i would realy like using it.

[ekwoka]

Is there a specific thing you're trying to do?

And init interceptors basically processes Interceptors, primarily things like $persist that register getter/setter pairs.

[anulax1225]

okay so with what you said, i would also need initInterceptors.

My need comes from a plugin i am making that enables component registration and reusable single file components via WebComponents. My plugin is inspired by vui-mesh but with major differences in the way the components data are handled.

For my part i wanted the components setup script/function to be fully integrated in alpine data stack. To do this i can use addScopeToNode, evalute. But for my purpose after evaluating the setup function of a component, i would like to inject the magics and init interceptors on the data before doing addScopeToNode so that it behaves like x-data, but without having to use x-data proceduraly.

The script setup is stored with the component and looks like this :

<script setup>
    return {
        init() {
            Alpine.effect(() => {
                let page = $store.router.currentPage;
                if (!compositor.hasComponent(page)) {
                    console.log("[Alpine router] Dynamic page load of " + page)
                    compositor.loadComponent(page);
                }
                $refs.routerView.innerHTML = `<${page}></${page}>`;
            });
        },
    }
</script>

if i could injectMagics, it would be easy to use this variables ($refs, $store, etc).

So from what you see, is it legitmate to do a pull request?

Sorry my answer is maybe a bit long, if you have any more questions feel free to ask.
And thank for your reply.

[ekwoka]

is there a reason you can't just use Alpine.bind(el, { 'x-data': () => DATAOBJECTHERE })?

[anulax1225]

Thanks for your solution, i think it's will do the trick. It wasn't clear from the docs what was the utility of this function in my case.

But i think, i will have to open an other discussion or PR because while testing your solution i found something weird.

The snippet comes from alpine - lifecycle.js and is used by x-ref to find the closest element with _x_refs :

export function findClosest(el, callback) {
    if (! el) return

    if (callback(el)) return el

    // Support crawling up teleports.
    if (el._x_teleportBack) el = el._x_teleportBack

    if (! el.parentElement) return

    return findClosest(el.parentElement, callback)
}

This piece of code doesn't handle shadow root elements. Shoudn't it look more like this :

export function findClosest(el, callback) {
    if (! el) return

    if (callback(el)) return el

    // Support crawling up teleports.
    if (el._x_teleportBack) el = el._x_teleportBack


    // same as in closestDataStack of alpine
    if (typeof ShadowRoot === 'function' && node instanceof ShadowRoot) {
        return findClosest(el.host, callback)
    }


    if (! el.parentElement) return

    return findClosest(el.parentElement, callback)
}

Or maybe refs are not allowed to pass shadow dom?