Skip to content
This repository has been archived by the owner on Nov 27, 2018. It is now read-only.

Defalt change event not triggered #48

Open
TheStickman opened this issue Apr 4, 2014 · 10 comments
Open

Defalt change event not triggered #48

TheStickman opened this issue Apr 4, 2014 · 10 comments

Comments

@TheStickman
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@seanwash
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

@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
Copy link

cphoover commented Jul 9, 2014

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
Copy link

hmaack commented Nov 4, 2014

@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
Copy link
Owner

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

@pocketwod
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants