Braintree multiple setup calls yield in multiple onPaymentMethodReceived events - javascript

I'm using angular, and in an angularUI modal window I want to show the Drop In form from Braintree to get a payment method. Thus, I create the usual form (partial.html):
<form id="creditCard" >
<div id="dropin"></div>
<button type="submit" id="btnPay" >Pay</button>
</form>
and then I show the modal with this:
var modalInstance = $modal.open({
templateUrl: 'partial.html',
controller: 'ModalController'
});
Where ModalController contains the call to the Braintree setup:
braintree.setup($scope.clientToken, 'dropin', {
container: 'dropin',
onPaymentMethodReceived: function (result) {
$scope.$apply(function() {
$scope.success = true;
// Do something else with result
});
}
});
This will show the Drop In form from braintree nicely (the setup generates the form) and accept the credit card and expiration date, all working fine so far.
The problem is, each time I call the modal, the ModalController is executed, and thus the braintree.setup() is also executed. Then, when I enter the credit card number and the expiration date and hit pay, the onPaymentMethodReceived() event is triggered once per setup execution! That is, if the first time I call the modal it will trigger the event once, the second time it will trigger it twice, and so on. Like if each time I call setup, a new hook to the event is created.
Any idea on how to avoid this? Is there a way to "unbind" the onPaymentMethodReceived() event handler? I do need to call the setup several times since each time I call the modal, the clientToken may have changed.
Thanks for any help or pointer to help.

Calling braintree.setup multiple times in angular seems unavoidable, either for the asker's reasons, or simply because setup is called in a controller that may be instantiated multiple times in a browsing session – like a cart or checkout controller.
You can do something like this:
$rootScope.success = false;
braintree.setup($scope.clientToken, 'dropin', {
container: 'dropin',
onPaymentMethodReceived: function (result) {
if(!$rootScope.success) {
$scope.$apply(function() {
$rootScope.success = true;
// Do something else with result
});
}
}
});
I found I wasn't able to avoid having the callback fire multiple times (the number of times seems to explode each time I revisit the view - yikes), but I could test whether I had performed my actions in response to the callback. Since the $scope will be destroyed if I leave the view, $scope.success is effectively reset when I need it to be. Because each new controller will have its own $scope, setting a success flag on the $scope may only halt additional executions on that $scope (which seems to still be available to the callback, even if the controller has been "destroyed"), so I found that using $rootScope meant only one execution total, even if I re-instantiated the controller multiple times. Setting $rootScope.success = false in the controller means that once the controller is loaded, the callback will succeed anew – once.

I think it's handled by the API since then with teardown:
In certain scenarios you may need to remove your braintree.js integration. This is common in single page applications, modal flows, and other situations where state management is a key factor. [...]
Invoking teardown will clean up any DOM nodes, event handlers, popups and/or iframes that have been created by the integration.
https://developers.braintreepayments.com/guides/client-sdk/javascript/v2#teardown
(I haven't tried it yet)

The link given by Arpad Tamas does not contain the info anymore. So I am posting the info given by BrainTree for posterity ;) Especially since it took me a few tries to find it with a Google search.
In certain scenarios you may need to remove your Braintree.js integration. This is common in single page applications, modal flows, and other situations where state management is a key factor. When calling braintree.setup, you can attach a callback to onReady which will provide an object containing a teardown method.
Invoking teardown will clean up any DOM nodes, event handlers, popups and/or iframes that have been created by the integration. Additionally, teardown accepts a callback which you can use to know when it is safe to proceed.
var checkout;
braintree.setup('CLIENT_TOKEN_FROM_SERVER', 'dropin', {
onReady: function (integration) {
checkout = integration;
}
});
// When you are ready to tear down your integration
checkout.teardown(function () {
checkout = null;
// braintree.setup can safely be run again!
});
You can only invoke teardown once per .setup call. If you happen to call this method while another teardown is in progress, you'll receive an error stating Cannot call teardown while in progress. Once completed, subsequent calls to teardown will throw an error with this message: Cannot teardown integration more than once.
I've wrapped this code in a function that I call each time the related checkout ionic view is entered.
$scope.$on('$ionicView.enter', function() {
ctrl.setBraintree(CLIENT_TOKEN_FROM_SERVER);
});
var checkout;
ctrl.setBrainTree = function (token) {
braintree.setup(token, "dropin", {
container: "dropin-container",
onReady: function (integration) {
checkout = integration;
$scope.$emit('BTReady');
},
onPaymentMethodReceived: function(result) {
...
},
onError: function(type) {
...
}
});
// Prevents a call to checkout when entering the view for the first time (not initialized yet).
if (checkout) {
// When you are ready to tear down your integration
checkout.teardown(function () {
checkout = null; // braintree.setup can safely be run again!
});
}
};

Related

AngularJS / IonicFramework prevent multiple API calls on toggle

I've read this and am trying to implement similar functionality
"If you’re using toggle buttons, e.g.: to turn something on and off and it hits an API endpoint, be sure to wrap that interaction in a timer so you’re not calling that endpoint multiple times if the user decides to tap the control multiple times in quick succession. Wait a second, then hit the endpoint."
I have a settings page with a series of toggle switches. Rather than do an API call at the change of each and every toggle I want to delay the API call that passes the value of the scope to my server. I want to delay it by X seconds. However, by doing this
$scope.settingsChange = function () {
$timeout(function () {
//save_notifications
console.log('called');
// Trigger API call
}, 3000);
};
All that's happening its just delaying the call by 3000ms. I still get the console log appear 3 times if I toggle something 3 times.
I'm fully aware this is because I've implemented a timeout function. I'm not sure what to implement to get the functionality the poster alludes to in my quote above.
Any ideas much appreciated.
Thanks,
Note: my template looks like this
<ion-toggle ng-repeat="item in settingsData"
ng-model="item.checked"
ng-checked="item.checked"
ng-change="settingsChange()">
{{ item.text }}
</ion-toggle>
once you initiate the API call, block any other calls from being made.
$scope.settingsChange = function () {
if ($scope.processingSettingChange) return;
$scope.processingSettingChange = true;
$timeout(function () {
//save_notifications
console.log('called');
// Trigger API call
$scope.processingSettingChange = false;
}, 3000);
};
you might also want to disable the UI while the API is processing the request. You should be able to using the same $scope variable and ng-disabled

Knockout observable subscription fires multiple times

I have an observable subscription inside a function that reiterates on certain events:
ko.computed(function() {
alert('computed fired');
self.obs2.subscribe(function() {
alert('subscribe fired');
});
return self.obs1();
});
I noticed that when that function runs, the code inside the subscription isn't executed, but when the subscription finally fires, the code inside it runs as many times as the reiterating function ran before it fired.
It was too complex to reproduce in JSfiddle, so I settled for a simpler, but similar example using a subscription inside a computed observable:
http://jsfiddle.net/norbiu/7hGNb/
Clicking on 'Edit Obs2' a few times will cause the alert to fire each time
Clicking on 'Edit Obs1' a few times will cause the first alert to fire, not the one inside the subscription
Clicking on 'Edit Obs2' once will cause the alert inside the subscription to run multiple times.
Is there a way to make the subscription run just once without having to move it outside the reiterating?
You will subscribe on your obs2 as many times are your computed evaluates.
I have no idea what do you want to achieve with subscribing on a different property inside a computed. I'm quite sure that there is a more proper solution exist to your use case...
However one possible workaround is to store the returned subscription object when calling subscribe and if there is an already stored subscription exists dispose it before subscribing again on your obs2:
self.subscription = null;
ko.computed(function() {
alert('computed fired');
if (self.subscription)
self.subscription.dispose();
self.subscription = self.obs2.subscribe(function() {
alert('subscribe fired');
});
return self.obs1();
});
Demo JSFiddle.

how can I determine when Google Maps loadGeoJson completes?

I have a scenario where users can store their mapping styling. When a user navigates back to that page with the map it should display the map the way it was previously.
The user can change colors of geographies, and borders as well as apply thematic styles based on demographic information.
With the release of the new loadGeoJson I have had great success with speeding up my application, Initially I was drawing all of the geographies myself, via JS. This was causeing some memory issues at around 1500 geographies. This new functionality decreases it significantly. I am choosing to generate the Features objects on the server side and just pass a URL to the map for rendering. This URL is passed in along with all of the other style information to rebuild the map as it was previously.
The problem I'm encountering, is when I attempt to apply the stylings, the map hasn't retrieved its list of features to be displayed on the map.
Looking through the documenation I don't see any events specifically for the loadGeoJson method, but did see for addfeature and setgeometry, but neither of these events get raised when using the loadGeoJson method.
This has all been written in Typescript and tries to adhere to a pretty strict MVVM approach using Knockout to handle all of UI changes for me via binding.
Is there another event I can tie into to see when this method has completed so I can apply my styles appropriately?
Is there another approach where I can bake in a 'wait' somewhere? .
addfeature event is definitely invoked by loadGeoJson, if isn't for you is some setup error.
loadGeoJson has an optional callback parameter what is invoked after all features were loaded and has the features as parameter.
https://developers.google.com/maps/documentation/javascript/3.exp/reference
loadGeoJson(url:string, options?:Data.GeoJsonOptions,
callback?:function(Array))
You can signal your code from this callback that it can continue processing.
map.data.loadGeoJson('google.json', null, function (features) {
map.fitBounds(bounds); // or do other stuff what requires all features loaded
});
You could also wrap loadGeoJson into a promise and resolve the promise in loadGeoJson's callback.
function loadGeoJson(url, options) {
var promise = new Promise(function (resolve, reject) {
try {
map.data.loadGeoJson(url, options, function (features) {
resolve(features);
});
} catch (e) {
reject(e);
}
});
return promise;
}
// Somewhere else in your code:
var promise = loadGeoJson('studs.json');
promise.then(function (features) {
// Do stuff
});
promise.catch(function (error) {
// Handle error
});
You can listen to addFeature event which will be fired for each feature in your json. e.g. if you use https://storage.googleapis.com/maps-devrel/google.json six events are raised after the json request is completed i.e. when google api starts adding the features from the json file:
You can see the demo here : http://jsbin.com/ofutUbA/4/edit
One would assume, if you are using knockout, to maybe bind onto some listeners, or attach listeners to an event.
Most events through JavaScript always have a callback function, this is good practive so that once a function has finished executing some long I/O or Database query it will immediately execute that function. Obviously that callback will be defined by you.
someLongTimeFunction(function (data) {
// usually this callback will be fired when the function has finished.
});
If you are familiar with knockout, then you would know that once the data has been retrieved and you pass through an observable that observable would update its binding.
Here is the link for extending observables: knockout js
As far as I can understand from you question, this loadGeoJson, is it server side? If so, you do a long poll from client side and tie into that:
function doRequest() {
var request = $.ajax({
dataType: "json",
url: 'loadGeoJson',
data: data,
});
request.done(function(data, result) {
if (result !== "success") {
setTimeout(doRequest, 10000);
}
});
}

Why doesn't Angular ignore subsequent $digest invocations?

The following must be the most common error Angular.js developers have to troubleshoot at some point or another.
Error: $apply already in progress
Sometimes, a $scope.$apply call wasn't required after all, and removing it fixes the issue. Some other times, it might be needed, and so developers resort to the following pattern.
if(!$scope.$$phase) {
$scope.$apply();
}
My question is, why doesn't Angular merely check for $scope.$$phase and return without doing anything when a $digest loop is in invoked, or when $scope.$apply is called, rather than complain and throw an error so insidiously hard to track down.
Couldn't Angular just check for $$phase itself at the entry points of any methods which trigger a $digest and save the consumers from having to go through the trouble?
Are there any implications in leaving misplaced $scope.$apply calls around, other than unwanted watches firing, which the check for $$phase would prevent?
Why isn't a$$phase check the default, rather than an oddity?
Background
I'm upgrading Angular from 1.2.1 to 1.2.6 and that exception is being thrown when the page loads, so I have no idea where it's originating from. Hence the question, why is it that we even have to track down this obscure sort of bug with no idea of where in our code to look for it?
If you ever get this error, then you're using $scope.$apply() in the wrong place. I think the reasoning behind this error is as follows: if you're calling $apply in the wrong place, you probably don't fully understand the reason it exists, and you may have missed places where it actually should be called.
If such lapses are allowed to go by silently (by always testing $scope.$$phase first, for example), it would encourage sloppy usage, and people might get holes in their "$apply coverage". That kind of bug (where a $scope change is not reflected in the view) is a lot harder to track down than this error message, which you should be able to debug by examining the stack-trace (see below).
Why does $apply exist?
The purpose of $apply is to enable automated two-way data binding between $scope and view, one of the main features of Angular. This feature requires that all code that may potentially contain a $scope modification (so, basically every piece of user-code) is run below an $apply call in the call-stack. Doing this properly is actually not that complicated, but I think it's not documented very well.
The main 'problem' is that Javascript can have any number of active call-stacks, and Angular is not automatically notified about new ones. A new call-stack is created whenever an asynchronous callback is triggered, e.g., from a click, a timeout, a file-access, a network response, and so on. It's very common to want to modify the $scope inside such a callback function. If the corresponding event was provided by Angular itself, everything will just work. But there are times when you'll want to subscribe to 'outside events'. Google Maps events, for example:
function Controller($scope) {
$scope.coordinates = [];
//...
var map = new google.maps.Map(mapElement, mapOptions);
google.maps.event.addDomListener(map, 'dblclick', function (mouseEvent) {
$scope.coordinates.push(mouseEvent.latLng);
});
}
http://jsfiddle.net/mhelvens/XLPY9/1/
A double-click on the map of this example will not trigger an update to the view because the coordinates are added to $scope.coordinates from an '$applyless' call-stack. In other words, Angular does not know about Google Maps events.
How and where to use $apply?
We can inform Angular about the event by using $scope.$apply():
function Controller($scope) {
//...
google.maps.event.addDomListener(map, 'dblclick', function (mouseEvent) {
$scope.$apply(function () {
$scope.coordinates.push(mouseEvent.latLng);
});
});
}
http://jsfiddle.net/mhelvens/XLPY9/2/
The rule is to do this first thing inside every callback function for an outside event. The "$apply already in progress" error is an indication that you're not following this rule. If you have to handle Google Maps events often, it makes sense to wrap this boilerplate code in a service:
app.factory('onGoogleMapsEvent', function ($rootScope) {
return function (element, event, callback) {
google.maps.event.addDomListener(element, event, function (e) {
$rootScope.$apply(function () { callback(e); });
});
};
});
function Controller($scope, onGoogleMapsEvent) {
//...
onGoogleMapsEvent(map, 'dblclick', function (mouseEvent) {
$scope.coordinates.push(mouseEvent.latLng);
});
}
http://jsfiddle.net/mhelvens/XLPY9/3/
The onGoogleMapsEvent events are now Angular-aware, or 'inside events' if you will (I'm totally making these terms up, by the way). This makes your code more readable and allows you to forget about $apply in your day-to-day programming; just call the wrapper instead of the original event subscriber.
For a number of events, Angular has already done this for us. With the $timeout service, for example.
Debugging the "$apply already in progress" error
So let's say I use the wrapper, but, absentminded as I am, I still call $apply manually:
onGoogleMapsEvent(map, 'dblclick', function (mouseEvent) {
$scope.$apply(function () { // Error: $apply already in progress
$scope.coordinates.push(mouseEvent.latLng);
});
});
http://jsfiddle.net/mhelvens/XLPY9/4/
This $apply call does not follow our placement rule (onGoogleMapsEvent events are not outside events, after all; we granted them 'insideness'). If you double-click on the map, you'll see the error appear in the logs, together with a stack-trace:
Error: [$rootScope:inprog] $apply already in progress
...
at Scope.$apply (.../angular.js:11675:11)
at http://fiddle.jshell.net/mhelvens/XLPY9/4/show/:50:16
...
at Scope.$apply (.../angular.js:11676:23)
at dl.ondblclick (http://fiddle.jshell.net/mhelvens/XLPY9/4/show/:33:24)
...
I've left only the relevant lines: the ones that refer to Scope.$apply. When you get this error message, you should always find two Scope.$apply calls on the stack (or Scope.$digest calls, which serve a similar function; $digest is called by $apply).
The topmost call indicates where we got the error. The other one indicates why. Go ahead and run the Fiddle with your Javascript console opened up. In this case we can conclude: "oh, this was an 'inside event' subscriber, I can just remove my manual $apply call". But in other situations you may find out that the call lower down on the stack is also not positioned properly.
And that's precisely why I believe the error is useful. Ideally you'd only get an error when you neglect to call $apply altogether. But if Angular could do that, there would be no need to call the function manually in the first place.

Avoiding a Javascript race condition

My users are presented a basically a stripped down version of a spreadsheet. There are textboxes in each row in the grid. When they change a value in a textbox, I'm performing validation on their input, updating the collection that's driving the grid, and redrawing the subtotals on the page. This is all handled by the OnChange event of each textbox.
When they click the Save button, I'm using the button's OnClick event to perform some final validation on the amounts, and then send their entire input to a web service, saving it.
At least, that's what happens if they tab through the form to the Submit button.
The problem is, if they enter a value, then immediately click the save button, SaveForm() starts executing before UserInputChanged() completes -- a race condition. My code does not use setTimeout, but I'm using it to simulate the sluggish UserInputChanged validation code:
<script>
var amount = null;
var currentControl = null;
function UserInputChanged(control) {
currentControl = control;
// use setTimeout to simulate slow validation code
setTimeout(ValidateAmount, 100);
}
function SaveForm() {
// call web service to save value
document.getElementById("SavedAmount").innerHTML = amount;
}
function ValidateAmount() {
// various validationey functions here
amount = currentControl.value; // save value to collection
document.getElementById("Subtotal").innerHTML = amount;
}
</script>
Amount: <input type="text" onchange="UserInputChanged(this)">
Subtotal: <span id="Subtotal"></span>
<button onclick="SaveForm()">Save</button>
Saved amount: <span id="SavedAmount"></span>
I don't think I can speed up the validation code -- it's pretty lightweight, but apparently, slow enough that code tries to call the web service before the validation is complete.
On my machine, ~95ms is the magic number between whether the validation code executes before the save code begins. This may be higher or lower depending on the users' computer speed.
Does anyone have any ideas how to handle this condition? A coworker suggested using a semaphore while the validation code is running and a busy loop in the save code to wait until the semaphore unlocks - but I'd like to avoid using any sort of busy loop in my code.
Use the semaphore (let's call it StillNeedsValidating). if the SaveForm function sees the StillNeedsValidating semaphore is up, have it activate a second semaphore of its own (which I'll call FormNeedsSaving here) and return. When the validation function finishes, if the FormNeedsSaving semaphore is up, it calls the SaveForm function on its own.
In jankcode;
function UserInputChanged(control) {
StillNeedsValidating = true;
// do validation
StillNeedsValidating = false;
if (FormNeedsSaving) saveForm();
}
function SaveForm() {
if (StillNeedsValidating) { FormNeedsSaving=true; return; }
// call web service to save value
FormNeedsSaving = false;
}
Disable the save button during validation.
Set it to disabled as the first thing validation does, and re-enable it as it finishes.
e.g.
function UserInputChanged(control) {
// --> disable button here --<
currentControl = control;
// use setTimeout to simulate slow validation code (production code does not use setTimeout)
setTimeout("ValidateAmount()", 100);
}
and
function ValidateAmount() {
// various validationey functions here
amount = currentControl.value; // save value to collection
document.getElementById("Subtotal").innerHTML = amount; // update subtotals
// --> enable button here if validation passes --<
}
You'll have to adjust when you remove the setTimeout and make the validation one function, but unless your users have superhuman reflexes, you should be good to go.
I think the timeout is causing your problem... if that's going to be plain code (no asynchronous AJAX calls, timeouts etc) then I don't think that SaveForm will be executed before UserInputChanged completes.
A semaphore or mutex is probably the best way to go, but instead of a busy loop, just use a setTimeout() to simulate a thread sleep. Like this:
busy = false;
function UserInputChanged(control) {
busy = true;
currentControl = control;
// use setTimeout to simulate slow validation code (production code does not use setTimeout)
setTimeout("ValidateAmount()", 100);
}
function SaveForm() {
if(busy)
{
setTimeout("SaveForm()", 10);
return;
}
// call web service to save value
document.getElementById("SavedAmount").innerHTML = amount;
}
function ValidateAmount() {
// various validationey functions here
amount = currentControl.value; // save value to collection
document.getElementById("Subtotal").innerHTML = amount; // update subtotals
busy = false;
}
You could set up a recurring function that monitors the state of the entire grid and raises an event that indicates whether the entire grid is valid or not.
Your 'submit form' button would then enable or disable itself based on that status.
Oh I see a similar response now - that works too, of course.
When working with async data sources you can certainly have race conditions because the JavaScript process thread continues to execute directives that may depend on the data which has not yet returned from the remote data source. That's why we have callback functions.
In your example, the call to the validation code needs to have a callback function that can do something when validation returns.
However, when making something with complicated logic or trying to troubleshoot or enhance an existing series of callbacks, you can go nuts.
That's the reason I created the proto-q library: http://code.google.com/p/proto-q/
Check it out if you do a lot of this type of work.
You don't have a race condition, race conditions can not happen in javascript since javascript is single threaded, so 2 threads can not be interfering with each other.
The example that you give is not a very good example. The setTimeout call will put the called function in a queue in the javascript engine, and run it later. If at that point you click the save button, the setTimeout function will not be called until AFTER the save is completely finished.
What is probably happening in your javascript is that the onClick event is called by the javascript engine before the onChange event is called.
As a hint, keep in mind that javascript is single threaded, unless you use a javascript debugger (firebug, microsoft screipt debugger). Those programs intercept the thread and pause it. From that point on other threads (either via events, setTimeout calls or XMLHttp handlers) can then run, making it seem that javascript can run multiple threads at the same time.

Categories