Alpine: Shorthand syntax inside Vue

[imliam]

It is possible to run Alpine inside an element that is managed by Vue - and it will work fine using the long-form syntax for binding and events (x-on:click instead of @click).

However, the short-form doesn't work, understandably as Vue would be typically handling these attributes being used.

I'm not super familiar with the Vue internals myself, but would it be possible to make Alpine take precedence for these attributes being used when inside an element managed by Vue that is not itself a template (either a single file component or using inline-template) as I'm not aware of Vue doing anything with them?

Reproducible example of Alpine not working here: https://codepen.io/LiamH/pen/abzRdBm

My thought behind this is that Alpine is good to get going, but if you end up using Vue at a later date and wrap your body with Vue as many people do, it'd suddenly break any usage of the shorthand syntax inside the application, even if Vue is not handling them at all.

[TomS-]

Why would you use Alpine with Vue? If you swap from Alpine to Vue in your project I would look to refactor to Vue.

[imliam]

1) Depending on the project size, there'd be a transitionary period where you ideally wouldn't want to replace huge chunks of logic like that all at once
2) I think Alpine still has its place alongside Vue in some scenarios. Vue can handle all the things Alpine can, but it does require moving the logic and data to a separate file, even when using Vue's inline-templates.

[TomS-]

I personally believe if you did want to use Alpine and Vue together you should not use shorthand, trying to get the "@" to take presedence over Vue seems like it will risk mixing intentions. x-on will be much better as you know when you're working in Alpine and when you're working in Vue.

[calebporzio]

I'm going to suggest not mixing the two.

Vue takes control of the DOM with its virtual-dom mappings, so it's almost impossible to deal with that the way Alpine is architected.

And I don't think it's a real architectural constraint. If you are in Vue, just use Vue. If you want to back out of Vue, do it one page at a time.

Sorry, I just think the road to supporting other heavy frameworks Vue is long and dark.

Good questions though!

[TheMangoTrain]

There are many plausible use cases for Alpine and Vue co-existing on the same page. For example...

Globally you have an Alpine mobile menu and cart drawer. On one route of your website you have a fullscreen Vue app, and you still want the global mobile menu and cart to be identical to global (of course). Essentially you just have two Alpine instances occurring on the same page, but outside of the Vue app container. In theory they don't know of each others' existence.

As a practical example, I've used Alpine for drawers (left, right, top, bottom), and two particular drawers house separate external Vue components: an auto-complete search component, and a product cart. Those components are pre-existing legacy code, and for the logic contained within (events, server communication, etc) it made sense to keep using Vue.

Seemingly the only hurdle to over come so far was to use full "x-" instead of the "@" shortcut. We're already doing this anyhow inside the Laravel Blade templates, since @ has different context there and IDE is giving warnings about it. Blade, Vue, Alpine... all use @ as a shortcut.