[Documentation] Using the new keyword is not synonymous to calling the library without it.
#14
Comments
|
+1, Gator is a factory, not a constructor. After removing support for |
|
In looking at this issue and @wesleytodd's PR #14 and working on another event delegation library, I realized there is actually a benefit to having multiple Gator instances per element... You can use it as a kind of "event namespacing," where events on a certain "namespace" are added to one instance can be removed wholesale if necessary, without affecting events added by other Gator instances... Currently, it's not possible to create more than one Gator instance per element despite there being a valid use case. However, if the behavior of
That is, instances created with With this proposal, the following would be possible: // A listener added elsewhere for clicks on the body
Gator(document.body).on('click', someoneElsesHandleClick);
// ...
// An application that uses events added with Gator
var myApp = { /* ... */ };
// A Gator instance for listeners related *only to myApp*
myApp.gator = new Gator(document.body);
myApp.gator.on('click', '.js-reset', myApp.reset);
myApp.gator.on('submit', '.js-signup', myApp.signup);
/// ...
// Remove all listeners related to myApp
// This should leave the listeners added on Gator instances other than myApp.gator
myApp.gator.off(); |
|
Personally I would rather have the straight forward behavior of of the constructor. Then have explicit namespaces for events, something like: But really I would rather that be a plugin or extension, not a part of the main library. The main reason I chose this library over others is that it only solves this one simple problem that I have...delegation. |
|
So in terms of Gator, @lazd is proposing a separate I think I personally think that Gator does very well being a factory (much like your first comment) and agree with @wesleytodd that the current ‘straight forward behaviour’ is probably exactly what people want. Especially those who – like me – find it via Microjs and only want it to handle events. Namespacing might be interesting to support. Is there some sort of consensus among libraries on how to namespace events? Quick Googling suggests only jQuery supports it and uses the format Edit: Google/JsAction actually seems to support it too, as |
|
@Zegnat, not quite, see this fiddle for a simple constructor that implements the pattern I'm describing, let's call it the Memoized Singleton with Override. Basically, the input is "memoized" and you get the same instance back for the same input, unless you call the constructor with This would allow both the factory pattern Since That said, I do feel that event namespaces are a more straight-forward pattern and most people will find familiar, but it does go against the "micro" nature of this library. The solution outlined above can help accomplish the same basic goal as namespacing -- give the user an easy way to remove a set of events all at once -- without the added complexity, but it is less flexible than namespaces because a listener can only be part of one instance, whereas, with namespaces, a listener can be part of multiple namespaces and will be removed when As far as the convention for namespaces, this is the pattern I've observed:
With the above algorithm, the implementation will behave as such: |
Currently the full documentation on create a gator instance reads:
This is wrong as those two calls are not synonymous. In fact, using the
newkeyword will break code. Bug reproduction:Clicking the button will throw a TypeError.
Please remove the mention of the
newkeyword method from the documentation.The text was updated successfully, but these errors were encountered: