Dmx-bind:value not working within a form inside a repeat

Wappler General Need Help
1

Wappler Version: 5.4.2
Operating System: Windows 11
Server Model: Capacitor
Database Type: N/A
Hosting Type: N/A

Expected behavior

The input should display the value from the bind

Actual behavior

The input displays [object Object]

How to reproduce

  1. Create a dmx-repeat and add an input and bind a value from within the repeat
  2. Add a form within the repeat and add an input in the form and attempt to bind the same value as in the input in step 1.

Here’s an example. It shows an input outside of the form and an input & textarea inside the form. All are binding the same value, but only the input outside of the form properly displays the value.

I had a similar issue in Feb 22 that doesn’t look like it was fixed either. Dmx-bind stops working in a repeat - #14 by psweb

2

This was the fix. Thanks @bpj! :slight_smile:

I changed dmx-bind:value="Description" to dmx-bind:value="$value.Description"

Data Store and Form Repeat

1 Like
3

I ran into the same issue and struggled to understand @ bpj's explanation, so here's what AI said:

Let me explain why this issue occurs and why the $value.id fix works:

  1. Scope Conflict Issue:

  • When you have a form input with name="id" inside a repeat loop that also has an id property in its data

  • The input's name and the data property name are the same (id)

  • This creates a scope conflict where the input's name is overshadowing the data property

  1. What's Happening:

  • When you use dmx-bind:value="id", Wappler is trying to bind to the nearest id in scope

  • Due to the naming conflict, it's binding to the input itself rather than the data property

  1. Why $value.id Works:

  • $value is a special Wappler syntax that explicitly refers to the current item in the repeat loop

  • By using $value.id, we're telling Wappler "get the id property from the current repeat item"

  • This bypasses the scope conflict because we're explicitly telling it where to find the value

It's similar to how in JavaScript you might have naming conflicts in nested scopes, and you need to be explicit about which variable you want to access. The $value prefix is Wappler's way of being explicit about the data source.

This is a common pattern in many frameworks - for example, in Vue.js you might use v-for="item in items" and then reference item.id to avoid similar scope conflicts.