paulstraw / FancySelect

A better select for discerning web developers everywhere.
http://code.octopuscreative.com/fancyselect/
MIT License
754 stars 165 forks source link

Defalt change event not triggered #48

Open TheStickman opened 10 years ago

TheStickman commented 10 years ago

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

return sel.val(clicked.data('raw-value')).trigger('change.fs').trigger('blur.fs').trigger('focus.fs').trigger('change');

Thanks

rjmccollam commented 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.

seanwash commented 10 years ago

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.

Ahrengot commented 10 years ago

This completely baffled me. Mostly because nothing in the readme mentions that this is how it works.

seanwash commented 10 years ago

@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/

Ahrengot commented 10 years ago

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. :)

seanwash commented 10 years ago

@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.

cphoover commented 10 years ago

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.

hmaack commented 10 years ago

@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?

paulstraw commented 10 years ago

Hey everyone. I think we're going to fix this by implementing the change outlined in this comment.

pocketwod commented 10 years ago

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.