I have a but of a weird situation…
I have a page that runs SC on load, the XHR request is made and I can see the data being returned in the network tab of Dev Tools but it is unavailable in dmx.app so can’t be used on the page:
What’s even weirder is the other items in the same request are available:
Does anyone have any ideas what might be happening?
There’s no console messages indicating any JS errors
I’ve never had any issues with DMX in JS over the years. It was always that I was on the wrong path looking at the wrong JSON.
If this is specific to 4.2.0, that would be really concerning.
Did you try printing just upto the data part and then expand and see what data is showing in the JSON?
Cheers, yeah I’ve never seen anything like this either. I’ve gone to dmx.app.data and opened from there too.
It’s so weird because there is an entry for each item that was returned in the query, just each is an empty object when you try to access it in dmx
I ran into this yesterday as well. Data was present in the data store when viewing in the application tab, but not present in dmx.app.data after I ran a flow that repeated over the data store. Luckily I could go around this, but I think we have a nasty bug here.
What are you doing with the data that disappeared? Do you do some manipulation with it, where is it used on your page?
If I recall correctly, it was a flow that amongst other things had a repeat on a data store array. In that repeat I was doing a setValue on something (I think an input or select) that itself was also driven by the data store array.
The whole thing turned out to be a bad design, so I started over and went another route.
In javascript arrays and objects are passed by reference, we try to always clone the object first before passing it, this prevents source data from being modified. It is possible that there are some places where it is passed by reference and then the original is being modified. That’s why we need to find out where that data was being used on the page.
I’ll see if I can recreate.
Okay, went a commit back and found it.
Here is the flow (which autoruns when displayed by a wrapping condition):
<div id="after_tour_loaded" is="dmx-if" dmx-bind:condition="tour_loaded.value">
<script is="dmx-flow" id="flow_after_tour_load" type="text/dmx-flow" autorun>{
repeat: {
repeat: "{{properties.data}}",
outputFields: [],
exec: {
steps: {
run: {
action: "{{each_selected_property.items[$index].time_property_tours.setValue(property_tour_datetime.formatDate('h:mm a'))}}"
}
}
},
name: "repeat_each_property"
}
}</script>
</div>
each_selected_property is a repeat on the page driven by the data store “properties”
<div class="row row-cols-1 mt-4" is="dmx-repeat" id="each_selected_property" dmx-bind:repeat="properties.data" key="$id" dmx-hide="property_search_open.value">
And inside that repeat is a select “time_property_tours”.
Interesting. This item was being used as the expression in a flow repeat step too!
<script is="dmx-flow" id="flow_getdashdata" type="text/dmx-flow">{
repeat: {
repeat: "{{sc_dashitems.data.q_mydashitems}}",
outputFields: [],
exec: {
steps: {
runJS: {
function: "rundashsc",
args: ["{{$value.dashboard_itemservconnid}}"]
}
}
},
name: "repeat",
output: true
}
}</script>
Is the data back when you disable the repeat step in the flow? It seems to be related to the repeats in flows, will also do some testing.
Yes, if I simply disable the repeat, everything stays intact.
Same here
Hey @patrick,
I hate to press but I have an urgent update to a web app that I need to publish but if I do, the elements of the site that this relies on will break unless I roll my Wappler version back which would be a PITA. Rather than wait for Thursday, if you come up with a patch fix, could you post it to try?
You are a legend! That seems to have done the trick. I’ll do a bit more testing and let you know if I spot anything. I don’t know what @george pays you but, whatever it is, I’m sure it’s not enough! Thanks
Yep, that fixes it.
This has been fixed in Wappler 4.2.1