Current behavior:
When using the plugin, the first instance of the recaptcha custom element loads in the Google API into the document - and following that resolving - calls this._initialize() where the loaded Google API is invoked to render the recaptcha. Part of this API invocation is to pass in the function reference for the callback that will receive the solved captcha value.
This works correctly, though only where this is either the first instance of the custom element or where this instance is only shown the first time. A use case for example is a simple scenario where the Aurelia router is used and navigates to a route with the recaptcha on. If the user navigates away to another route and then returns back to the first route (the one that contains the recaptcha), a new instance of the recaptcha custom element is constructed.
The current implementation expects this behavior and actually checks whether the API is already loaded and if so, continues onto the call to this._initialize() function to render the captcha, but the call to this._initialize() is actually too early (because no script loading was required) and therefor @bindable callback hasn't been set by Aurelia data binding yet. This results in a bug with a callback function reference of null being passed to the Google API.
Expected/desired behavior:
The subsequent instances of the recaptcha plugin should only call this._initialize() (to render the captcha via the Google API) after all Aurelia bindings have been resolved.
The fix is a simple change that requires adding a bind method to the custom element and instead calling the this._initialize() function from there.
E.g.:
bind() {
this_initialize()
}
A pull request will follow shortly.
What is the motivation / use case for changing the behavior?
Fix a bug in an already good and clean implementation.
Jaans
commented
7 years ago
I'm submitting a bug report
Please tell us about your environment:
Operating System: Windows 10
Node Version: 6.2.2
NPM Version: 4.1.1
JSPM OR Webpack AND Version webpack 2.1.0-beta.27
Browser: all
Language: all
Current behavior: When using the plugin, the first instance of the recaptcha custom element loads in the Google API into the document - and following that resolving - calls
this._initialize()where the loaded Google API is invoked to render the recaptcha. Part of this API invocation is to pass in the function reference for the callback that will receive the solved captcha value.This works correctly, though only where this is either the first instance of the custom element or where this instance is only shown the first time. A use case for example is a simple scenario where the Aurelia router is used and navigates to a route with the recaptcha on. If the user navigates away to another route and then returns back to the first route (the one that contains the recaptcha), a new instance of the recaptcha custom element is constructed.
The current implementation expects this behavior and actually checks whether the API is already loaded and if so, continues onto the call to
this._initialize()function to render the captcha, but the call tothis._initialize()is actually too early (because no script loading was required) and therefor@bindablecallback hasn't been set by Aurelia data binding yet. This results in a bug with a callback function reference ofnullbeing passed to the Google API.Expected/desired behavior: The subsequent instances of the recaptcha plugin should only call
this._initialize()(to render the captcha via the Google API) after all Aurelia bindings have been resolved.The fix is a simple change that requires adding a bind method to the custom element and instead calling the
this._initialize()function from there. E.g.:A pull request will follow shortly.