Alpine components (v3)

[timrosskamp]

Hey,

I'm opening this thread about the Alpine.component() feature thats in the V3 Roadmap. I'm personally very interested in this feature and would be happy to contribute to the development. But beforehand I thought it would be good to discuss the functionality, scope and syntax of such a feature. I would like to share my thoughs and ideas about this feature.

Functionality 🔨

The problem this feature should aim to solve is creating larger and more complex components. Implementing complex interactions with Alpine.js right now would end up with lots of javascript in your html. This gets messy and difficult to develop quickly.

With Alpine.component() this problem could be solved, because it would allow to move the "business logic" of your component into a js file.

Right now, reusing and extracting data/behavior is only possible with a global function that you call in your x-data attribute, but I'm personally not a big fan of this method, because I'd like to keep my global scope clean. Futhermore a true API for components would open up the possibility for livecycle hooks and other neat features available in other front-end frameworks.

Scope 📣

I think in its most basic form this feature should allow the user to define a component with a data object (what x-data does), provide an init callback (what x-init does) and attach behaviors in the form of methods to your component.

Syntax 💬

I can think of two ways to implement a components API.

The simple way would be to define a component with a name and pass a function which returns a new data object:

Alpine.component('foo', () => ({
    bar: false,
    activate(){
        this.bar = true
    }
}))

This would be really similar to calling a function in the x-data directive, but keeps things out of the global scope.

A different syntax could be to pass an object as the second argument, but this would require data to be a function. This is similar to Vue.js.

Alpine.component('foo', {
    data(){
        return {
            bar: false
        }
    },
    activate(){
        this.bar = true
    }
})

This syntax might be better and more extensible in the long run.

I would really like to hear other opinions about this, so please comment what you think about this.

To init the component we need to reference the component name in our html. I would suggest to introduce a new directive like x-component="foo". Another option is to extend the existing x-data
directive and init the component if a reference to a predefined component is found.

This basically sums up my thoughts and expectations about the components feature. I'm very open for criticism, new ideas and comments so please reply! 🕶️

[ryangjchandler]

Hi @timrosskamp,

Caleb and viewers went through the syntax and API for this on a livestream not too long ago - you might be able to find the VOD on his channel.

The syntax discussed was very similar, if not identical, to your second idea. The data would be returned from a function called data or similar.

We also discussed the concept of automatically calling an init function, so that you don't need to do the x-init part yourself. We landed on the use of a function called __init I believe, which would be called automatically upon component initialisation.

It's worth adding that this "components" API will be implemented alongside some other new APIs in v3, so the ideas might change along the way to better support those APIs.

[ryangjchandler]

I've got a CodePen here with an API that can be used with v2 - it's a bit of a workaround for custom directives, where the custom x-component directive is just translated into the underlying x-data and x-init version.

Play around with it here: https://codepen.io/ryangjchandler/pen/mdeGmxo

This is the same approach that Spruce takes with the x-subscribe directive.

Since Alpine waits for the DOM to be ready, this code works well. It would probably be safer to put this under the window.deferLoadingAlpine function.

Final note is that the function callback for your component doesn't need to be defined on the window as a top level property. You could create a global object, similar to the Alpine object that hosts all of your component functions.

[timrosskamp]

Thanks for your quick reply!

I guessed, that you guys already discussed this topic and got an idea about the syntax and so on. I just found that livestream, thanks for pointing that out!

Would you be interested in development contributions on these new APIs? I'm not sure if there is already ongoing work and if so, I don't want to intervene. But if it's helpful, I'll be happy to work on an implementation.

[mblarsen]

I just found that livestream,

Do you mind posting the link? Thanks

[timrosskamp]

There you go: https://www.youtube.com/watch?v=Z8TzJa3LiAM

The conversation about components is at the beginning.