Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Make use of jQuery configurable #608

Closed
IgorMinar opened this issue Oct 19, 2011 · 8 comments
Closed

Make use of jQuery configurable #608

IgorMinar opened this issue Oct 19, 2011 · 8 comments

Comments

@IgorMinar
Copy link
Contributor

See discussion at #556 (comment)

It would be useful to be able to tell angular to always use jqlite (even when jquery is present) or maybe even specify which jquery instance to use (since there can be multiple).

@0x-r4bbit
Copy link
Contributor

+1 for that! Currently having the problem that in my environment a jQuery 1.4.1 is given and I don't want to rely on that crappy release.

@MihaiValentin
Copy link

Hi Igor,

What about checking for a global variable called angularjsUseJquery which can point to any jQuery instance, or if it's value is "internal", then point to jqLite inside angularjs?

I can provide a pull request with this for review.

@gjohnson
Copy link

Any reason why this can't happen?

@marknadig
Copy link
Contributor

Discussion over here on a PR.
#2163

@ghost ghost assigned jeffbcross Jan 11, 2014
@torifat
Copy link

torifat commented Jan 19, 2014

@IgorMinar I have started working on this issue like you suggested here -> #2163 (comment)

But, I'm confused about the following things-

  1. If the user has jQuery but he wants to configure angular with JQLite may I still need to patch jQuery?
  2. I think it is better to let people access the config (read only) so that they can check which one is loaded. I was thinking something like angular.options or angular.config. Please suggest.

@IgorMinar
Copy link
Contributor Author

Great questions!

#1: the answer is either no or yes but with a different set of patches. The purpose of the patches is to intercept destructive operations and clean up references that would otherwise create memory leaks.

If jquery is used only by some unrelated code that never interacts with the DOM that angular is in charge of then we don't need to patch it.

Otherwise we need to patch it but instead of cleaning up jquery storage we need to find the corresponding jqlite data storage records for the DOM being destroyed and destroy the references in jqlite.

I haven't thought about this enough but I'd skip the patching for now. The patch might not be compatible with the jquery version being used and it might be surprising to get jquery patched and possibly broken just because you loaded it on a page with angular.

#2: yes, that sounds like a good idea. I'm not sure what the api should look like right now, but it should be something on angular namespace.

@torifat
Copy link

torifat commented Jan 20, 2014

@IgorMinar Thanks for the reply 😄

Get it. Then need to rethink about jQueryPatchSpec.js a bit. This test runs if jQuery is available. Have to check it via angular.options or angular.config. BTW, which one do you suggest, angular.options or angular.config?

I was thinking about giving Zepto a try by passing it as jquery. Will let you know the results.

@mgol
Copy link
Member

mgol commented Apr 2, 2015

This is now resolved as of 09ee82d

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

No branches or pull requests

9 participants