TheSharpieOne
commented
8 years ago On second though, why not just keep track of the last widgetId internally in the service and use that by default. 99.99999% of the time, there will only be 1 widget on the page, and that will most likely be the last widget. If by default, when no widgetId is passed to reset() and getResponse() the service uses the internal value it keeps of the last widgetId to pass when calling the reCaptcha functions.
This is a RFC to make widgetId required when passed to
reset()andgetResponse(). I suggest this even though the widgetId is optional in reCaptcha itself. I believe reCaptcha did this because their use case often is not a SPA where multiple reCaptcha instances will be loaded without a page refresh/reload. For their use case, only 1 instance is often loaded and stays loaded, thus the default widgetId is usually valid. In angular, SPAs are the norm and more times than not, the instances of reCaptcha will come and go without a page reload. This means the default widgetId is less likely to work as the associated widget is no longer on the page. The convenience of not passing a widgetId is lost as most times developers should be passing a widgetId just to account for the fact that the end-user may load the page (with the recaptcha widget), navigate away, then come back. In this case, using the default widgetId will throw an error as that widget is no longer on the page. The convenience is also lost when developer don't pass a widgetId and get errors from reCaptcha's scripts (since the widget/instance being references no longer exists) and do not know how to resolve them (and the resolution is to pass the widgetId). There are quite a few open and closed issues which are directly related to developers not passing a widgetId and the first widget no longer on the page.