You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the Pub/Sub model is nice, especially when written with such a thin wrapper, it is useless when not exposed outside the plugin. I can't find a justification for exposing the Pub/Sub given what it currently does, so it is probably best to scrap it and move on to a different model.
The next step is to find a different design pattern to follow. The design pattern needs the following:
Can work well or be adapted to work with Dedicated Workers
Handles multiple forms/objects (takes advantage of Proxy?)
Reduces complexity before it increases it
Is easy to pick up for new comers
Singleton speaks to me, as it could look something like this:
classWeHateCaptchas{constructor(){this.instances=newWeakMap();}getInstance(form){// ... do object get stuffs}}
This is appealing as it would only be one class to manage, and there would be no need to create multiple objects for each form.
The form would act as the key in the WeakMap, with the value being an object holding the worker. Messaging between the worker thread and the main could be handled with a Proxy object that is also stored in the WeakMap. This adds a layer of complexity that is not needed though.
There are other details to iron out with this pattern, such as DOM manipulation, messaging, and more.
The text was updated successfully, but these errors were encountered:
While the Pub/Sub model is nice, especially when written with such a thin wrapper, it is useless when not exposed outside the plugin. I can't find a justification for exposing the Pub/Sub given what it currently does, so it is probably best to scrap it and move on to a different model.
The next step is to find a different design pattern to follow. The design pattern needs the following:
Singleton speaks to me, as it could look something like this:
This is appealing as it would only be one class to manage, and there would be no need to create multiple objects for each form.
The form would act as the key in the WeakMap, with the value being an object holding the worker. Messaging between the worker thread and the main could be handled with a Proxy object that is also stored in the WeakMap. This adds a layer of complexity that is not needed though.
There are other details to iron out with this pattern, such as DOM manipulation, messaging, and more.
The text was updated successfully, but these errors were encountered: