Return Alpine proxy data object

[asbjornu]

As with #203, I would like to interact with an Alpine data component through out-of-scope JavaScript. I know I can use events to do communicate between the outside and inside, but as this particular case is a JavaScript class holding some state, which given some external conditions, eventually initializes an Alpine component, that's a bit cumbersome. All the communication would be between the outer class and the inner Alpine Data component, after all.

I could of course merge all of the surrounding code into the Alpine component, but that makes the interaction with the JavaScript class from both itself and from the outside very awkward. Not being able to use private fields, static methods, etc. is very limiting.

While following the Alpine.js best practice usually works fine, being able to interact with an Alpine data component more ergonomically from JavaScript is highly desirable.

There are currently at least two hacks available to get around this. One is document.querySelector('["x-data"]').__x and another is to wrap the initialization of Alpine in a Promise:

function initializeFoo() {
    return new Promise((resolve) => {
        document.addEventListener('alpine:init', () => {
            Alpine.data('Foo', () => ({
                init() {
                    resolve(this);
                }
            }));
        });
    });
}

const foo = await initializeFoo();

An imho better option would be for the Alpine.data() method to return the proxied data object. As it currently returns undefined, that would be a non-breaking change that would remove the need to use the hacks described above.

[ekwoka]

This wouldn't work, purely because Alpine.data does not initialize a component.

You pass a component builder. The component is then initialized every time that data function is used in your document.

If you want one global one like this, then Alpine.store already works for this.

https://alpinejs.dev/globals/alpine-store

Is there a reason why Alpine store doesn't work for you?

[ekwoka]

Just make them public.

Its your code. Why bother making it runtime private?

[asbjornu]

Marking fields and methods as private acts as documentation of how the class is supposed to be used. It guides other developers in how to interact with the class as it was designed. But even making every field and method in the class public, I have difficulties getting the state propagated properly between the innards of the class and the Alpine data proxy.

You can see the issue I'm having in the following CodePen. Every click on a new link in the list of links should increment the number, but as you can see, Alpine's state is not in sync with that of the class other than for the @click event. Any help resolving this would be highly appreciated! 🙏🏼

[SimoTod]

If you use this in the constructor, you are accessing the real instance of the class. Alpine reacrivity works because it creates proxies around properties so it can detect when they change.

It should work if you do

class Incrementer {
  constructor() {
    this.number = 0;
    this.increment({ type: 'constructor' })
  }

  init() {
 window.addEventListener('hashchange', (event) => this.increment(event), false);
  }
...

[ekwoka]

Marking fields and methods as private acts as documentation of how the class is supposed to be used. It guides other developers in how to interact with the class as it was designed.

If you're using TypeScript, you can do this with the public and private keywords.

A lot depends on what your actual goals are, so the most I and @SimoTod can do is present multiple approaches.

Highly reduced examples of what issues you're having don't really help since most of them will fail to provide a compelling reason why they should be done that way at all.

I've made a lot of very capable, adaptive components and not really run into these issues, so it might be a major XY problem. Where you settled on Y as the way to do X, and are having issues, but Y just wasn't a good solution in the first place.

[asbjornu]

@SimoTod, ah, that makese sense – thanks! Everything now seems to work. Although I've been forced to make everything in the class public, I suppose that's an ok compromise to make.

If you're using TypeScript, you can do this with the public and private keywords.

True, but I'm not using TypeScript, just regular JavaScript.

I've made a lot of very capable, adaptive components and not really run into these issues, so it might be a major XY problem. Where you settled on Y as the way to do X, and are having issues, but Y just wasn't a good solution in the first place.

That might indeed be the case, but for now it seems like using a JavaScript class with public members is a good compromise. I'll probably refactor towards other patterns over time as I understand Alpine.js better. Thanks for the help – much appreciated! 🙏🏼