x-model directive does not work in the CSP build.

[Marijus]

Unfortunately, the x-model directive does not work in the CSP build. I've seen a closed PR that fixes the problem. Are there any plans to start supporting this directive?

[calebporzio]

Yeah, we definitely want to support that directive - can you submit a failing test as a PR and we can look into fixing it? Thanks!

[kg-currenxie]

So whats the alternative? 🤔

<script th:nonce="${cspNonce}">
  function initState() {
    window.Alpine.data('theme', function () {
      return {
        themeName: Currenxie.theme.getCurrentTheme(),
        changeTheme: function (event) {
          const newTheme = event.target.value
          Currenxie.theme.changeTheme(newTheme)
          this.themeName = newTheme
        },
      }
    })
  }
  document.addEventListener('alpine:init', initState)
  document.addEventListener('htmx:afterSwap', initState)
</script>
<div x-data="theme">
  <select
    class="rounded border-0 text-right text-on-surface-secondary"
    @change="changeTheme"
    x-model="themeName"
  >
    <option value="">Use system settings</option>
    <option value="light-theme">Light</option>
    <option value="dark-theme">Dark</option>
  </select>
</div>

Page load works, but the change events gives this warning:

[kg-currenxie]

I removed x-model, and added :selected="isSelected" on each <option>, with

get isSelected() {
  return this.themeName === this.$el.value
},

this is the way?

@Marijus maybe this could help your case

[ekwoka]

Currently, x-model internally requires unsafe-eval to work.

You can just remove the x-model here and you're fine.

[kg-currenxie]

Ok thanks. As I thought then. Replace x-model with 2 additional attributes; some change-handler, and some value-binding 👌

[ekwoka]

It might be possible for the CSP build it just bind these events directly without doing unsafe-eval but it might increase complexity.

[ncd76]

I can't use Alpine in non CSP version Who can when it needs unsafe-eval? Anyway...

x-model works unless nested?

Works:

<input type="number" id="runs_min" min="0" max="1000" x-model="filters_runs_min">

Does not work:

<input type="number" id="runs_min" min="0" max="1000" x-model="filters.runs.min">

Alpine.data('data', () => ({
        filters_runs_min: 9, // testing
        filters: { 
            runs: {
                min: 7, max: 1000
            }
        },
}))

Is this expected?

Thx...

[SimoTod]

I created a PR to support property accessors via dot notation: #4238

I don't know if and when it's going to be merged, though.

x-model will still be not working (it was broken in your example too): the current implementation cannot work with the CSP build because it needs to evaluate a string internally.
If you open the console, you can see that it binds the object but it will error when updating the value.

You need to manually bind value and update the property on input instead of using x-model.
Something like (assuming the PR above gets merged):

<div x-data="test">
  <span x-text="foo.bar"></span>
  <input id="runs_min" :value="foo.bar" @input="update">
</div>

<script>
  document.addEventListener('alpine:init', () => {
    Alpine.data('test', () => ({
      foo: {
        bar: 'baz',
        update(event) {
          this.foo.bar = event.target.value
        },
      },
    }))
  })
</script>

[ncd76]

Thx for your reply. It seems horrible to have to add getters and setters for every value. and without x-model would it not be reactive to the values changing from another source?

This is an example, the real application has dozens of inputs, so will become a pain to maintain in this way.

:value with nested values does not work for me.

I hacked together something that works even thou it throws an error: Alpine is unable to interpret the following expression using the CSP-friendly build: "get_input_value = __placeholder"

Your PR looks to do something similar, but obviously far superior.

I'd love to use Alpine due to its simplicity, but cannot due to CSP rules. This CSP build is more of a hassle than Vue or React thou, so its main benefit is lost. I'd much rather be a help than a hinderance thou! Is there anything that can be done that I can help with to make the CSP build useable?

<!DOCTYPE html>
<html lang="en">
<head>
  <script defer src="https://cdn.jsdelivr.net/npm/@alpinejs/[email protected]/dist/cdn.min.js"></script>
</head>
<body>
  <div id="app" x-data="data">
    <input
        type="number"
        id="runs_min"
        min="0" 
        max="1000"
        path="filters.runs.min"
        @input="update_input_value"
        x-model="get_input_value"
    >
  </div>
  <script>
    document.addEventListener("alpine:init", () => {
        Alpine.data('data', () => ({
            filters: {
                runs: {
                    min: 7
                }
            },
            get_input_value() {
                const properties = this.$el.getAttribute('path').split('.');
                return properties.reduce((obj, prop) => obj[prop], this);
            },
            update_input_value(event) {
                const properties = this.$el.getAttribute('path').split('.');
                properties.reduce((obj, prop, index) => { if (index === properties.length - 1) {
                    obj[prop] = event.target.value;
                    console.log(obj[prop])
                } return obj[prop]; }, this);
            }
        }))
    })
  </script>
</body>
</html>

[SimoTod]

Yeah, that error comes from the internal implementation of x-model. At the moment that directive is not csp friendly so it cannot be used unless rewritten.

Just to clarify (I hacked together something that works even thou it throws an error: Alpine is unable to interpret the following expression using the CSP-friendly build: "get_input_value = __placeholder"), it does not work as it should do: it binds the value correctly but when you change it, it's not going to update the value back to your component.

[ncd76]

Yea, I understand its not going to update the UI if I update the data value. I'll keep my eye on this project but can't really do any production code in it. Shame.

[ekwoka]

the real application has dozens of inputs, so will become a pain to maintain in this way.

Is there a need to model all of them?

You can just use FormData to get the data.

You can also just listen for input/change events on a parent and then organize the data off that one handler.

your larger code sample doesn't need x-model at all. Especially since you passed in a function to the x-model...

you can just :value and @change to do everything x-model does...

[confuzeus]

I have encountered the same problem while building a complex form. It looks like Alpine can't be used in this situation if you require CSP and maintainability. The solution is worse than using vanilla JS.

I ended up loading Preact on this particular page for now until Alpine comes with a solution.