Component syntax with expanded <script> tags

[markhuot]

I really like Alpine. Like—like, like, it. But one thing I struggle with is shoving a bunch of javascript in to HTML attributes. Even with PHPStorm able to inject the JavaScript language in to the attribute I still find over half of my Alpine bugs feel like catchable bugs where I miss a ; on a multi-expression statement that I accidentally shoved in to a short closure, or something like that.

For example, I write a lot of Alpine that looks like this,

<form @submit.prevent="$axios.post('/contact', new FormData($el)).then(() => { $el.querySelectorAll('input').forEach(el => el.value = ''); alert('Success!'); }).catch(err => alert(err.response.data.message))">
  <div><label>Name: <input type="text" name="name"></div>
  <div><label>Comment: <textarea name="comment"></textarea></div>
  <div><button type="submit">Submit</button></div>
</form>

I love the DX of Alpine—keeping my functionality and HTML close together feels right. But I keep finding myself wishing Alpine was more like JSX/React where we could write real JavaScript (or something that looks and feels like real JavaScript). Maybe something like this,

<script type="alpine/attribute" x-on="submit.prevent">
  $axios.post('/contact', new FormData($el))
    .then(() => {
      $el.querySelectorAll('input').forEach(el => el.value = '');
      alert('Success!');
    })
    .catch(err => alert(err.response.data.message))
</script>
<form>
  <div><label>Name: <input type="text" name="name"></div>
  <div><label>Comment: <textarea name="comment"></textarea></div>
  <div><button type="submit">Submit</button></div>
</form>

Here the alpine/attribute <script> tag would be applied to whatever element immediately follows the tag. The benefit here is it's an actual <script> tag so existing IDEs should highlight/type check/etc… it. All out of the box.

Is this a crazy idea? is there a better way that I should know about?

[ekwoka]

You coul make a simple magic that would do this.

But you can write the component in a script tag...or functions in the script tag...

and then access them.

<script>
  async function doStuff(form) {
    const response = await fetch('/contact', { method: 'post', body: new FormData(form) })
    if (response.ok) cleanData()
  }
</script>
<form @submit="doStuff($el)">
  <input type="text">
</form>

I'm not sure that the approach you present there makes enough sense as an alternative to the existing system to justify it in the core.

But a plugin to add a magic that would do it would be quite simple, but I do fear the DX....

[markhuot]

Hum, that's not half bad and feels very Vue-y (in a good way). It's sort of an Alpine-based <script setup>… Maybe thinking of the <script> tag as a setup block and not individual handlers (like I have above) would simplify things,

<script setup="alpine">
const xData = {name: ''};
async function handleSubmit(event) {
  const response = await fetch('/contact', { method: 'post', body: new FormData(form) })
  if (response.ok) cleanData()
}
</script>
<form @submit.prevent="handleSubmit">
  <input type="text" x-model="name">
  <button>Send</button>
</form>

I think I could get together a plugin that dynamically creates a component scope based on <script setup="alpine"> element… But I have no idea if I could parse out the functions/variables from the scope of the script tag.

[markhuot]

Also, maybe at this point I've just reinvented Petite Vue? https://github.com/vuejs/petite-vue

[ekwoka]

Just not really worth it.

You can just do

<script type="module">
   import Alpine from 'alpinejs';
   Alpine.data('myform', () => ({
     async handleSubmit(event) {
        const response = await fetch('/contact', { method: 'post', body: new FormData(form) })
        if (response.ok) cleanData()
      }
    }
</script>
<form x-data="myform" @submit.prevent="handleSubmit">
  <input type="text" x-model="name">
  <button>Send</button>
</form>

or whatever.

Why go through all the work to make it just a different set of boilerplate?

[markhuot]

Why go through all the work to make it just a different set of boilerplate?

Yup, good point.

With the Alpine.data approach you add complexity though: juggling this and interacting with data props. I was hoping for a more 1:1 feel of in-line attributes but written in a way that IDEs can reason about.

Regardless, thanks for thinking it out with me! The Alpine.data approach may be the way to go for now.