Wappler Version : 6b3
Operating System : Mac M2
Server Model: node.js
Database Type: mySQL, Redis
Hosting Type: Docker (DO), mySQL (DO), Redis (DO)
Expected behavior
What do you think should happen?
In a form input field I expect the value referenced in the dmx:change to be the “previous” value of the select element. This functionality works as expected in the current stable version.
Actual behavior
What actually happens?
The value referenced in dmx:change is the “updated” or newly selected value in the field.
How to reproduce
<dmx-array id="arrTest"></dmx-array>
<div class="container">
<div class="row">
<div class="col">
<form id="form1">
<div class="form-group mb-3">
<label for="select1" class="form-label">Select Test</label>
<select id="select1" class="form-select" dmx-on:updated="arrTest.add(selectedValue)" dmx-on:change="arrTest.add(value)">
<option value="1">Option One</option>
<option value="2">Option Two</option>
<option value="3">Option Three</option>
</select>
<small id="select1Help" class="form-text text-muted">Enter a help text for your select.</small>
</div>
</form>
</div>
</div>
</div>
If you monitor the array arrTest you’ll see the same value is inserted by both the before and updated events.
Actually the change event is now doing the correct thing, it should have the new value instead of the old version. We always had the problem that the App Connect state was a bit behind the actual DOM state, so it didn’t had the value directly since update was delayed for performance optimizations. Due to that problem we introduced the changed event that triggers after the App Connect was updated to have the updated value from the DOM.
With App Connect 2 we finally fixed the whole updating of the state, it is now directly and the DOM change event triggers after the value was updated.
I’ve now put in a small delay again for form elements to update its value to mimic the old App Connect behavior and for backward compatibility for users that depend on the old behavior.
I’d look into refactoring if using the dmx:change event as a “before event” is an anti-pattern. What would a better/more standard approach be? Capturing the previous values in a data store/variable and manipulating that way?
There are also three different events available dmx:change, dmx:changed, and dmx:updated. If I understand your comment correctly would they all ideally behave the same in AC2? Or is the delay you mention now a supported feature? Can dmx:change reliably be used in conjunction w/ dmx:updated to execute before and after update events? Thanks!
The events should now more behave as the old App Connect. The changed event was introduced to do what the change actually should do but was impossible in previous App Connect. The updated event triggers anytime the value changes, this can be on any input event or by a binding while the change(d) event only triggers by user interaction.
Confirmed that beta 13 returns the results expected in the before/after values. However, the functionality that raised the issue initially is not resolved. I’m using a custom formatter that Ken wrote that is used when you have a series of select fields on a form and when you select a value in one of the selects, it’s removed as a valid option for the others. What I’m seeing is that when I enter a value in “select 1” and then a value in “select 2” the value in “select 1” is wiped out. The implementation is identical to what Ken has here wappler_formatter_samples/public/js/custom_formatters.js at master · mebeingken/wappler_formatter_samples · GitHub Thanks for your help Patrick! If AC2 enables other solutions for this type of functionality, I’m happy to get feedback.
Hi @umadmin, I’m using the same custom formatter within a formRepeat and in v6.0.0 Beta channel, the already selected values keep getting removed. This is working correctly in v5.8.2. I reported this issue here with a couple of videos.