-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alive? #64
Comments
I would also like to know. Also does it still work? |
Yes, it still works |
Yes, it should still work, but I don't use this anymore, and haven't had a chance to check. There is in fact a better version in the 2.0 branch, but I haven't gotten around to writing documentation for that. |
@scdoshi Nice to hear from you. We're at LotusTM interested to maintain and develop plugin further. Any chances for gettings contributors rights or transferring repository to our organization? |
@scdoshi +1 to move this repo to an organization or at least give permissions to people who wants to contribute! |
If someone takes over, I've created a fork based on the 2.0 branch that observes all forms on the page, allowing dynamic content to work with the library. I'm very happy if it's useful to anyone. I wrote it as I needed it for my current project. https://github.com/pbowyer/jquery-ajaxchimp/tree/observe-forms |
@pbowyer that's an interesting approach using delegated events, did not know how that worked and learned something new, so thanks! Since dynamically adding forms would happen in javascript anyways, it doesn't seem like a problem to call ajaxchimp on the element right after adding it to the DOM and it would be more readable to me in that it's immediately obvious what is happening. (less magic) It's also easier to chain different callbacks for each form on the page if ajaxChimp was called separately on them, or at least there was an option too. Anyways, it's easy enough to fork the repo, so glad you got the solution you prefer |
Thanks for your reply, I saw you were already delegating for the 'submit' event rather than binding directly to it, so it was a small step to generalise further!
There's two advantages of using the delegated approach that I see: Less coupling - the callback is already cluttered with code being fired after load (Facebook, Google Analytics, the list grows) so one less is nice. More importantly for me, I suspect it is more performant. Getting rid of jank is hard, and the less JS that's run when the next section of content is inserted, the easier it is to keep scroll moving smoothly. I should benchmark one day to see what the difference is - maybe when this project is done :) Thanks for your response! |
Hi! @scdoshi So it's dead again? |
Seems that repository wasn't updated for quite a while, PRs remains unmerged.
Is it still alive?
The text was updated successfully, but these errors were encountered: