sometimes this error gets thrown and it blocks the gestures :
315[Intervention] Ignored attempt to cancel a touchmove event with cancelable=false, for example because scrolling is in progress and cannot be interrupted.
The docs mention this: https://use-gesture.netlify.app/docs/faq/#why-am-i-getting-warnings-from-preventdefault-after-i-pass-passivefalse
The lib does internal checks whether events are cancelable, but there’s no way it could prevent the user from
performing its own logic.
verify if you are using something to prevent some action to happen like:
event.preventDefault();
and make some verification first
if (event.cancelable) event.preventDefault();
Related
I am trying to decide what to do to handle errors in my chat application using Socket.io and react. I can successfully get a 'connect_error' error so I can do something inside the socket.on('connect_error', ()=> //Do something) but I am having trouble getting any other type of error. I can't think of a scenario where I can modify the app or do something specific to trigger the socket.on('error', ()=> //Do something). Does anybody have an idea?
The 'error' event is not a specific one. It's by design, so ANY error event will trigger it. What you can do is console.log it.
So now, anytime you'll be able trigger any error (Which is what you want) you'll see its description, then you can google it and then write a more specific code to handle it.
If you can't trigger any errors no matter what you do, it's not a bad thing since it means things works correctly.
socket.on('error', (error) => {
console.log(error);
});
Getting [$rootScope:inprog] $digest already in progress [SANITIZED URL] in Meteor app using meteor-angular-templates
I have been getting this error is some places in my meteor app. I tried wrapping $apply calls in my app within a $timeout but that didn't work. I suspect it has something to do with Tracker.autorun() calls in my angular controllers. Does Tracker.autorun() follow the same digest and apply cycle as Angular? Is multiple function calls a reason that the view pages are being rendered again and again which cause $digest error.
Tracker.autorun(() => {
Multiple function calls here
})
logDNA screenshot
From the Docs:
Error: $rootScope:inprog Action Already In Progress
Diagnosing This Error
When you get this error it can be rather daunting to diagnose the cause of the issue. The best course of action is to investigate the stack trace from the error. You need to look for places where $apply or $digest have been called and find the context in which this occurred.
There should be two calls:
The first call is the good $apply/$digest and would normally be triggered by some event near the top of the call stack.
The second call is the bad $apply/$digest and this is the one to investigate.
Once you have identified this call you work your way up the stack to see what the problem is.
If the second call was made in your application code then you should look at why this code has been called from within an $apply/$digest. It may be a simple oversight or maybe it fits with the sync/async scenario described earlier.
If the second call was made inside an AngularJS directive then it is likely that it matches the second programmatic event trigger scenario described earlier. In this case you may need to look further up the tree to what triggered the event in the first place.
For more information, see
AngularJS Error Reference - $rootScope:inprog
I am writing a wrapper for material-ui/AutoComplete.
I want it to:
set value and submit on clicking the suggestions,
set value and submit on pressing enter on the suggestions,
navigate through list by pressing arrow keys
submit on clicking a submit button next to the AutoComplete button.
I realise that I need to capture three events:
onKeyDownCapture
onKeyDown
onNewRequest
All the events are handled using the same handler.
Among these events, onNewRequest is triggered as usual but onKeyDown is triggered when I press the enter button while onKeyDownCapture captures a click.
When the value updates, the component also triggers onNewRequest automatically, leading to duplicate and expensive calls to my search service.
Is there a way to block duplicate calls for search service?
Here is the code for my component:
handler(){
// calls search service.
}
render(){
return (
<AutoComplete
...{props}
onKeyDownCapture={this.handler}
onKeyDown={this.handler}
onNewRequest={this.handler}
/>
}
I tried an ugly "newRequestDuplicatesHandler" which basically keeps track of the last search request text and prevents the duplicate requests by comparing the new search request text. However this is not a clean solution.
The original code, as shown above causes duplicate requests.
However, the newRequestDuplicatesHandler does the trick. But this is not a clean solution.
I have a ng-click="myFunc(aEntry)"
And then myFunc is this:
MODULE.myFunc = function(aEntry) {
aEntry.hilite = true;
if (!confirm('Are you sure?')) {
aEntry.hilite = false;
return;
}
};
However it wont update the dom to show it highlighted. The confirm box seems to be pausing it. Does anyone know a work around?
It is because confirm is a blocking function. I understand you want to have a ui change, but
aEntry.hilite = true;
is not a UI change. It is a logical change. You probably have an event handler which runs after you have called confirm. You need to guarantee that the highlighting ui operation is performed before you call the confirm. There are several ways to do it.
The most primitive way is to use setTimeout and put your confirm call inside it, using a time, which is surely longer than the time you need to wait for the ui handler to be executed.
A slightly better approach is to use setInterval until the ui change has occured.
But the best approach would be to pass the confirm with a function wrapped around it used as a callback for the ui change or to trigger the ui change event before you call confirm.
I have an AngularJS application, that uses ui-router and ui-router-extras, where some transitions between states are intercepted and redirected to another ones.
So basically, when a $stateChangeStart event is triggered, the app checks if that transition is allowed or needs to be blocked and then redirect the user somewhere else (eg: a login dialog, a missing step in the process, etc...). Transitions can be also cancelled.
The interception works this way:
$rootScope.$on("$stateChangeStart", function(e,to,toParams,from,fromParams){
if( <mustBeIntercepted> || <mustBeCancelled> ){
// this prevents the actual state change from happening
e.preventDefault();
if( <redirectionRequired> ){
$state.go( <stateName>, <stateParams>);
}
}
});
And this works nicely so far. The problem is that when cancelling a state change, $previousState is not aware of the cancellation, and registers the current one as previous, in the same way that if you do not cancel the transition. So basically $previousState is unaware of the transition cancellation. This causes that when trying to return to the previous state programmatically, it does not move because $state == $previousState.
I created a live demo here: http://plnkr.co/edit/dXjj2iSwDU1DtPMuqW1W?p=preview
Basically, you click on Step1, and then on Confirm, the app will cancel the transition and prompt you if you want to confirm. If you confirm, then it will transit to the originally desired state. Note that in the real app this is not done with confirm but with a custom overlay that cannot block for an answer in the same way that confirm does.
As you will notice, in the top bar there are two labels that show the content of $state and $previousState. If you cancel the confirm prompt, you will see that $previousState changes to "Step1" despite of that the transition didn't happen.
How can I avoid this?
The bug was reported and it has been resolved: https://github.com/christopherthielen/ui-router-extras/issues/120