How to use init() in multiple x-data spreads? - alpine.js

Question

I've split up my methods into two functions in a separate JS file. Both parts need x-init, but only the second part's init() method is triggered:
<div
x-data="{
...part1(),
...part2(),
}">
<p>Check the console</p>
</div>
document.addEventListener('alpine:init', () => {
Alpine.data('part1', () => ({
init(){
// Not triggered
console.log("Part 1 init");
}
})
)});
document.addEventListener('alpine:init', () => {
Alpine.data('part2', () => ({
init(){
console.log("Part 2 init");
}
})
)});
Codepen
Can we have 2 init()s in one x-data?

Answer 1

The simplest solution here, if it's an option, would be to use two separate
DOM elements:
<div x-data="part1()">
<div x-data="part2()">
<p>Check the console</p>
</div>
</div>
However, I understand this might not be desirable.
Due to the way the object spread operator works, your init method from part1 is being overwritten with the one from part2 before AlpineJS even sees it. If you plan to do a lot of this type of merged data object, you might consider writing a helper such as:
Alpine.magic('merge', (...inputs) => inputs.reduce((state, next) => {
const prevInit = typeof state.init === 'function' ? state.init : () => {};
return {
...state,
...next,
init() {
prevInit.call(this);
next.init.call(this);
}
};
}, {});
<div x-data="$merge(part1(), part2())">...</div>
Depending on what you're doing, you might consider writing this as a directive instead. At least as of Alpine v3, it's possible to add multiple x-init directives as long as they're namespaced. For example:
<span x-init.foo="console.log('foo')" x-init.bar="console.log('bar')"></span>
You would implement this as:
document.addEventListener("alpine:init", () => {
Alpine.directive('part1', (el, {expression}) => {
Alpine.bind(el, {
['x-init.part1']() {
console.log('part 1 init');
}
})
});
Alpine.directive('part2', (el, {expression}) => {
Alpine.bind(el, {
['x-init.part2']() {
console.log('part 2 init');
}
})
});
});
You might end up with issues using this approach, though. In general simpler is better.