How to combine components by namespace in x-data?

[jameslkingsley]

I want to build a set of reusable components that I can combine together into a single x-data. However, in order to keep it maintainable I want to keep them namespaced.

Eg:

<div x-data="{ sidebar: app.sidebar(), foo: app.bar() }"></div>

In this example I should be able to do things like <button @click="sidebar.open"> and utilise the methods and properties within each namespace.

In the app.sidebar() method, it would then return an object like so:

export default () => ({
    opened: false,

    open() {
        this.opened = true
    }
})

However, in practice this doesn't work because this inside each component does not refer to what you might expect. And even if I did this.sidebar.opened it still doesn't work.

I'm not sure whether this is currently possible with Alpine, or maybe there's a different way to setup the exported function so that this refers to the object properly.

Any help would be great!

[ryangjchandler]

@jameslkingsley If the component properties don't cross over, you could spread each one out:

x-data="{ ...app.sidebar(), ...app.bar() }"

Now, you can access opened and open() inside of your component. I'd recommend prefixing each variable name too, perhaps sidebarOpen or openSidebar().

[jameslkingsley]

Yea I considered the spread with prefixing the variable names, it's just a bit cumbersome after a while to do that.

Just had an idea...

It would be cool if Alpine could separate these scopes using something like:

<div x-data.sidebar="{ open: false }" x-data.foo="{ open: false }">
    <button @click="sidebar.open = true"></button>
    <button @click="foo.open = true"></button>
</div>

Then internally that would manage two separate reactive objects, and each object would only have access to itself.

Could this be something supported by Alpine? I might look into a PR if it doesn't sound like a lot of work.

[SimoTod]

I think it's already possible using x-data="{sidebar: {...app.sidebar()}, foo: {...app.bar()}}"

[SimoTod]

However this kind of composition doesn't fix any problem. If, from your bar object, you refer to the sidebar variable your implementation is coupled and you can't really reuse the bar object in different places unless you also include sidebar.
An event driven communication would probably be better from a design perspective (it's about the first example you posted).