This might be something that goes a little against the project's philosophy, but I'll put it out there nonetheless.
I think it would be neat if we could (optionally) define a controller class/object/whatever for Alpine, that would bind to existing HTML in the same way Stimulus does.
I'm envisioning something like the following (basically a modified copy of Stimulus's conventions):
class MyController extends AlpineController {
data = { testInput: null, testCheckbox: null, submitted: false };
connected() { // lifecycle hooks
this.data;
this.$refs;
}
async submitForm($event) { // long-form event handlers
await fetch(...);
// do a million other things
this.data.submitted = true;
}
}
Alpine.controller('my-controller', MyController);
md5-61df03db64132d4ad6bbc04c2f22f403
I'm doing something similar with an actual Stimulus + alpine combo, but there are some pain points (very verbose html, communication between a Stimulus controller and alpine).
I've looked through alpine's source, but I didn't grok it fully yet, so I'm unaware of any technical challenges that could arise, but would love your thoughts!
Maybe I don't fully get the idea, but what would be the benefit of this over using the approach described in Extract Component Logic in https://github.com/alpinejs/alpine/blob/master/README.md#x-data ? As far as I can see, such a behaviour should basically work, shouldn't it?
What @thormeier said.
Here's what your controller example would look like with the current strategy.
What do you think? (didn't test the exact code, but should work)
function myController() {
return {
testInput: null,
testCheckbox: null,
submitted: false,
init() { // some init hook
//
},
submitForm($event) { // long-form event handlers
fetch(...).then(() => {
this.submitted = true;
})
},
}
}
md5-f6dcc569e5f6c6ee643bf24892facd1c
Most helpful comment
What @thormeier said.
Here's what your controller example would look like with the current strategy.
What do you think? (didn't test the exact code, but should work)