Open TheStickman opened 10 years ago
Just wanted to say that this has worked flawlessly when I have used it and would like to see this included in the build by default.
I believe the correct thing to do is explicitly listen for event.fs
, like change.fs
for example. The events were namespaced so that we don't run into conflicts with other plugins or functionality in larger apps.
This completely baffled me. Mostly because nothing in the readme mentions that this is how it works.
@ahrengot,
How can we make this more clear for users? Currently every event that's listed in readme.md has the namespace .fs attached to it.
Also, for example, the Chosen docs (that I can see anyway) just list events with their namespace as well: http://harvesthq.github.io/chosen/
Hey @seanwash,
With plugins like this, that change the DOM, it's always a little different how plugin authors handle event dispatching (Or if they rely solely on callbacks), so it's really key to have that part well documented. Another question is wether the events fire from the new generated element or the old select input.
Under the Basic Usage headline, I would put an example that alerts the selected item:
var handleChange = function(e) {
alert( e.target.value );
}
// Events are fired from the original <select> element, but namespaced under .fs
$('select').on( 'change.fs', handleChange ).fancySelect();
Oh, and please don't take this the wrong way. I really like the plugin so far, and I think it's fantastic that you have template filters. That's the main reason I went for this one over chosen etc. :)
@Ahrengot no hard feelings at all! We're all in this together, and anything we can do to help encourage contributions helps everyone in the long run! I'll have a chat with @paulstraw about this and get back to you.
It would be nice to have an option to delegate the synthetic change event to the underlying select. I don't want my client code to necessarily listen to your specific fs
event namespace. And that's not a jab at your plugin, but I might want to switch it out so something else in the future depending on the need.
@cphoover I agree. Currently I am working on a small backbone / -epoxy app and all bindings are listing on the default events e.g. 'change' . @seanwash what do you think about an option as argument?
Hey everyone. I think we're going to fix this by implementing the change outlined in this comment.
Thanks to @Ahrengot for your post and @seanwash for writing this awesome plugin. I am new to jQuery specifically and without @Ahrengot post there is no way I would have figured that out after viewing the ReadMe and website.
I have a form that listens for a change event when a select's value changes, however it seems like fancySelect is swallowing this event so it's never fired.
I can fix it by listening for change.fs, but that doesn't seem like the right thing to do. It would be better I think to change line 165 to
Thanks