Hhmm could it be a this.notify() triggered in the delegate, that happends really soon (170ms after didmount)?
Edit: seems i was on 8.12 again, still i think it was the same?
i put in some logs and this is what i see in order:
this is what i see in order:
(C=component, I = ignition)
C: component did mount()
C: sending messages to gateway (requesting data)
I: inital onchange triggered by project (setting the prop to default)
C: onready triggered (setting the prop to 0)
I: binding onchange (setting to 0)
C: reponse of gateway recieved in delegate
C: trigger this.notify() to get the response data in to display
I: onchange triggered by browser (THE BUG) (setting the prop to default)
C: rendered response data
Sometimes i notice:
my component sets before the initial triggers inwhich case this happens:
C: component did mount()
C: sending messages to gateway (requesting data)
C: onready triggered (setting the prop to 0)
I: inital onchange triggered by project (setting the prop to default)
I: binding onchange (setting to 0)
C: reponse of gateway recieved in delegate
C: trigger this.notify() to get the response data in to display
I: onchange triggered by browser (THE BUG) (setting the prop to default)
C: rendered response data
I: binding onchange (setting to 0)
So i put a timeout on right before the notify of 500ms and The buggy writing triggers right after it. So it seems they are linked? or its something else down the line that happends idk its not an async wait so it could be anything, but its clearly something thats triggering it and not something due to missed gateway timing (i think)
Altho removing this notify didnt do anything (im triggering notifies on other places too tho) sigh xD
seems something else got broken in 8.1.12+ related to extensionfunctions
tho i doubt its related to this, as this extension function doesnt get used that much
Iâm so incredibly confused. We fixed the issue in the project you supplied, but that was not the actual problem? Youâre going to have to supply a project that clearly demonstrates your problem. I was not aware that you were using a custom component delegate to fetch data from the Gateway. Thatâs another variable to consider. Feel free to send a DM containing other resources, like screenshots, gifs, or short videos.
I can not supply you with the component i am working on. So i made a simpler component that seemed to replicate the behavior i was seeing.
But seems it might be something deeper too.
Ahah! we have done a new discovery, it seems its might not really related to my component at all!
Or its just another thing that came up⌠8.1.14
Popup with some viewparams, the custom props are bound to the viewparams and the textinput are bound to the custom keys. Everything is set to bidirectional.
In my original tests i was using a binding on the view params. but to put a binding on a view param it needs to be in and out put. so maybe that was the problem? Although i have no idea why the first param keeps functioning⌠Something weird is going on xD
Using our own views it sometimes even happend on every change! just like i thought happened on every click of my component! However yet again it seems to be tough to replicate. It is using embedded views with bidirectional bindings and some on change scripts and stuffâŚ
Actually i think i have already seen an update a while ago about input/output viewparams that i think was aimed at this⌠idk if it was before 8.1.12 or after tho.
It might have been related to params being set back to default if the popup gets dragged (which was update 8.1.12?)
@ynejati
Its not a problem for me anymore but i got reminded of this in an other post so just giving a friendly poke as it might be worth investigating to see if it happends for you too
Do you think it is possible that a lot of the headache you are encountering might be stemming from the use of a bi-directional middleman between the view parameters and component properties?
Ah, turning view parameters to input only would seem to fix it. It appears that the output view parameters being stored within the Popups state might be in a race. Output view params on the Popup donât really make much sense anyways since they donât get written to anywhere, just stored locally to prevent reverting to the defaults. And yes, youâre correct it is related to that fix, since that is when we introduced the method of storing output parameters. Also, having deferUpdates and rejectUpdatesWhileFocused on the text inputs could be contributing to the issue. Not sure until I investigate further.
Yea thats true, putting on bindings is not possible on input bindings though. But that ofcrouce doesnt make much sense to do anyways. Still since you already prevent bindings on input bindings, maybe its worth investigating to not allow bindings on input/output viewparams too to avoid this behaviour.
Things like this are hard to debug when they would happen to an unsuspecting designer^^
While it seemed neccecary to replicate the bug, i'm pretty sure the origin of the bug is in the viewparams. Maybe it thinks the "BindingWriteback" isnt valid which causes the browser to go back to the default value idk. It definitly is related, but it seem to be the viewparam that is getting overruled by the browser.
Hey. Thanks for the response. That project you sent over was really helpful. We are looking into it now to see what needs to be done. Iâll let you know what comes of it. Thanks, again.
Hey hey, i dont remember... was this ever fixed? i seem to be having some browser origins changes again and i remebered this bug. But it was with a bunch of other things so i cant really find it
edit:
heh seems like it was... guess i'll have to look else were xd
Hey, sorry. Yes, that fixed it at the surface (on the front-end). But, it turns out that there was also a little race condition that was causing similar behavior (on the backend). This race was fixed in 8.1.23. I would hope that both of these resolved your issue.
