[BUG - 5694] BREAKING BUG ViewParams 8.1.12 (For custom components?)

@ynejati @PGriffith @cmallonee @Kevin.Herron

(sorry if i referred to some unrelated staff, you 4 just seem to be the most active xd)
I have made a copy of your radComponent of github (might be an older version) and made a tiny adjusment to the image, just added in a tree.write which triggers on ever render that returns the date. Nothing special.

Then i’ve made a view which opens a popup with the binding as i have setup.
Most of the time (not always it seems) it also triggers the browser revert at the start
image

Please take a look into this
ive proved an export of the 2 views and the adjusted module
RadComponents-unsigned.modl (113.3 KB)
testStorage_2021-11-23_0043.zip (5.8 KB)
In my other project it sometimes even triggers not on startup, but all the time. But its hard to replicate even with my own component… But it has to be related to this.

Thank you for the additional information. Give me a little time to wrap my head around the situation. I’ll get back to you soon.

1 Like

Wait, is your custom component also writing back the tree in the render method? That will result in an infinite loop.

No it’s not, my component only writes at the start and on some client click events.
I just made this example as simple as possible xd As it seems i can only replicate it if it triggers very fast i figured the render would be the way.
In my project it also happends on the click events (so every write?), but i dont seem to be able to replicate that even if i copy the view.
I also was hoping one of these triggeres in the infinite loop would also get set back but seems that wasnt the case. I have no idea why i cant replicate what happens on the click events, but it gotta be related to this happening at the start too somehow. Some new write back in the main code somewhere?

Yes I encountered this as well. Whenever I would open up a popup it would reset the page params on the original view. Wound up recoding both views to only use params on startup.

1 Like

Welcome, Mitchell_Dennis.

Will you please explain to me how you have your popup configured. I’m not sure what “original view” means. Are you saying that your popup View is writing back to a property of the Page on startup? By “reset” you mean writing the value of a persistent property? Is this happening occasionally or is it consistent and easily reproducible? Thanks.

Scratch that. I’m able to reproduce the issue. Doing some investigating. Will respond with what I find. Thanks.

1 Like

It’s an incoming view property update that arrives after the popup is closed, gets stored (a mechanism of async view loading), and then applied once the popup opens again, but seemingly out of order. If you don’t interrupt the property sync between the view and the gateway, i.e. not closing a popup abruptly mid sync, you shouldn’t encounter this issue. Also, if it’s the first time opening the popup, you also shouldn’t encounter this issue. Anyways, we already have a solution, currently awaiting review, that is meant to address this general behavior. I’m glad you brought this up. We should have a fix up soon. Thanks again.

1 Like

For me on one of my views it triggered on every tree.write(). but i wasnt able to reproduce it elsewhere. But i hope the fix on startup also fixes that one^^

Thanks for looking into it and finding a quick solution! Let me know if its in the nightly so i can test if it works

Hi, there will be something in the next nightly that should hopefully fix the issues you are seeing. At least, it does fix the initial write back from the browser, and we hope it fixes your other issue relating to clicking. Let us know. Thanks.

1 Like

Im busy with another project right now, but ill check when i can. Thank you !

Update?

Sorry ive had to get my appendicitis removed so i been on sick leave, ill also have to catch up on work when i get back so yeah…

Ouch! Understandable. Please, take your time. That was just meant to be a friendly reminder. Rest up.

1 Like

So i got the 8.1.15 nightly and im still seeing the initial write back.
Did i get the wrong version or has it been changed again?

Edit:
Hm no it does seem the banana gif isnt writing back anymore,
but my own component is...
sigh

anyways the click issue doesnt seem to happen again, but it was already hard to replicate so idk if that says anything right now xd

I must say the initial loading of my component isnt the cleanest, So it probably is interupting a bunch of things in itself, but i dont think that should trigger a de-sync on the popup level xd

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)

v8.12

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.

Okay.