Has anyone see this behavior?
I’ve got an web app that works great on a surface pro, laptop etc but on some iPads it will work for a while really well then just freeze up on a one Blaze view in particular.
The user needs to kill the browser then re-open it. Once they do that they are back in business… until next time which might never happen.
It only happens on this particular Blaze view that is doing quite a bit - I am thinking I probably need to reduce publication size and/or reactivity for this view but am unsure the best way to isolate and kill this issue to understand precisely what is causing this issue.
To the user it seems intermittent.
Any thoughts would be appreciated.
Reducing the complexity isn’t a bad step in general. Would be nice to know what exactly is the user doing. My first though would be that some function gets triggered and the execution of that function causes the freeze. I would recommend to take a look if you are looping through something there.
I think it’s the number of reactive vars - 12- and network latency and how those vars drive what shows and what is disabled and what is hidden etc.
I think if a button is tapped and there is a slight delay then the user will tap again and then the event will get queued up again which can cause a whole cascading effect of reactivity depending on what that button does.
On a slower iPad this is lag is enhanced. On more powerful devices you don’t see it.
I think in certain circumstances if buttons are disabled until callbacks complete it might solve my issue. But that just a guess.
Do you know for sure what the symptoms of the freeze are? I’m thinking high cpu is a classic sign of what I’ve previously termed “reactive runaway”. Typically that can be provoked by geting and seting the same reactive variable in a reactive context (template helper or autorun). So this would be an example:
Template.hello.onCreated(function helloOnCreated() {
this.someVar = new ReactiveVar(0);
});
Template.hello.helpers({
valueAndIncrement() {
const ti = Template.instance();
const value = ti.someVar.get();
ti.someVar.set(value + 1);
return value;
}
});
No I do not but yeah, that looks like something to investigate… thank you. There’s a lot going on in the View this occurs in and I could have introduced something like this.
This thread was all about how to identify such memory issues… suggestions welcome on techniques for debugging such issues.
I’ve also got like 30+ helpers that do various things many of which are driven by reactive sources so that’s where I was thinking on multiple taps the view could be cascading into oblivion running on the underpowered iPad that can’t keep up - some of our test devices are older iPads.
I am also going to be splitting up the view into smaller components at some point for testing purposes and to encapsulate reactive responsibility which should help.
1 Like