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
Cache objects in Utils.__cache instead of using $.data (#4014) #4346
Conversation
There are indentation changes in here that are going to prevent this from being merged in. |
I will fix the indentation. |
|
Sorry for the indentation issues. I fixed the EOL to be UNIX format. My editor had switched this to Windows format. Do you want me to add integration tests ? |
There's an integration test now...can this be merged in? |
Merged into |
Please also consider the following discussion regarding |
Sorry for posting here, but it feels relevant and I've tried to get support from the official channels with no answers yet. Although there’s a fallback in What I’m trying to do is access what was equivalent to: var instance = $element.data('select2'); But this no longer seems to be possible. Is there a public way of accessing the Is this not a sort of dangerous change to make in essentially a bug fix release in terms of breaking backwards compatibility? |
I'm here, just been busy with php[world] and traveling. |
To be fair, I've not exactly been waiting long for a reply (and it's a weekend!), but I didn't necessarily want to see this one slip into a stable release if there's something wrong. |
Yes, thanks @oh-ren and @chrisdeeming. I didn't realize that these changes affected the public API. But, it seems like this is meant to fix a bug (#4014). Honestly, I don't really understand the problem that this is solving as I have never encountered this myself. It seemed like a safe change, but apparently not. Is there a way we can fix this bug (whatever it may be) without causing a breaking change? Join me on my own chat server (https://chat.userfrosting.com/channel/select2) and we can discuss. |
@NadeemAfana any thoughts on this? Seems like this is breaking a lot of other aspects of Select2. |
|
Thanks! Yes, unfortunately Select2 is so big and widely used, and had been poorly documented for so long, and tends to attract the greenest types of developers, that it's part of the public API whether we want it to be or not 😦 Are there any use cases where people really need to be able to access Also, is there any chance that this modification is what is causing #5133? |
I would definitely deprecate
No, because I was able to reproduce the issue with |
We use the data stored there specifically to access the elements which are dynamically created by Select2, mostly as a shortcut. They are, specifically We could just find them in the DOM relative to element we've instantiated Select2 on but if they're already cached in the Select2 object then, why not? Point taken about invalid use cases but that's not something we'd do. |
I suggest to create a new method then, perhaps Not sure how other (popular) jQuery plugins implement getting a reference / access to the internal instance. It's not something uncommon, or is it? (Of course, there could be a big fat warning accompanying the method that relying on it is at your own peril 😉) (Coming to mind, off topic but somewhat related): @alexweissman Thanks for the invite, might check the channel out, but simply discussing here works best? |
@oh-ren I would indeed say that something similar to That said, the data attribute approach is not uncommon either. As a compromise, if there was a built in method which could get certain things (but not set them) then that would work too. |
Keep in mind also, that modifications to the internals of Select2 should be possible with custom adapters/decorators. Can you provide examples of other jQuery plugins that have a Incidentally, this seems like a perfect example of how Javascript's lack of visibility scoping can be frustrating. Perhaps we need a rewrite of Select2 into Typescript more badly than we realize 😁 At any rate, I've merged in @NadeemAfana's BC fix for release on |
0498d0e
to
66fbe4a
Compare
The tests now run for both jQuery 1.x and 2.x. This allows us to see if there is any discrepancy in the future. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hello, I have read through issue #5071 which lead me here. What I am trying to achieve is change a config option after initialisation and stumbled into the issue stated here https://stackoverflow.com/questions/37016655/select2-cannot-read-property-query-of-null regarding the error thrown within the dataAdapter. $('.country_select').on('select2:opening', (e) => {
if($(e.target).data('select2').options.options.minimumResultsForSearch == 5) return
$(e.target).data('select2').options.options.minimumResultsForSearch = 5;
let options = $(e.target).data('select2').options.options;
$(target).select2('destroy');
$(target).select2(options);
}) Any suggestions would be appreciated |
This pull request includes a
The following changes were made
Utils.__cache
instead of using $.dataUtils.__cache
$.data
codeThis is a bug fix for #4014