Remove jQuery dependency requirement?
FagnerMartinsBrack opened this issue · comments
The plugin internals does not rely that much on jQuery and semantically it doesn't make much sense, jQuery is a library created only to manipulate the DOM, the same is expected from its plugins.
Maybe at the time it made sense using jquery namespace to prevent globals cluttering, since everyone were including it, but today there are many applications that don't need jQuery at all, and in some cases having jQuery as a dependency is more a burden than a benefit.
I am not saying to remove jQuery dependency, that can't happen due to historical reasons. What I am saying is that, considering the actual tendency of using MV* frameworks like angular and the (slow but ongoing) official specs, one could think about using jquery-cookie being jquery an optional dependency.
The intent is to leverage an existent plugin to fit additional use cases, or make it easy to do so. angular cookie, for example, doesn't let ppl provide additional options to the cookie. A limitation already addressed by jquery cookie a long time ago.
It would be useful to expose a decent api to integrate easily with angular and other tools that doesn't rely exclusively on jquery.
The idea would be to do something like this for v2, since it means a break in backwards compatibility (a new namespace will break existing code).
I vaguely remember something like this being brought upon but couldn't find the issue.
Thoughts?
👍
At this point it only uses $.extend(). If we substitute the used subset of that method, it'd be a standalone library.
It already supports UMD etc. It'd be a small step to do something like export = { get: .., set: .., remove: .. }.
E.g. use like:
var Cookie = require( 'cookie' );
Cookie.set( .., .. );
Cookie.get( .. );
Cookie.remove( .. );Defaulting to exporting Cookie as a global, with aliased methods attached to jQuery (if available) for back-compat.
I'm open to this, though we'd need a new name for this whole thing I guess :)
We could create a small organization, copy the JS core without jquery and then specific projects for jquery, angular, etc. (mainly to provide name compatibility). The distribution code on jquery-cookie repo would remain unchanged. I am just not sure if cookies are still mainstream enough to justify all that work.
Simply renaming the project though would cause a lot of trouble for ppl using package managers, the plugins.jquery.com site, looking on google, asking things on stackoverflow, etc.
Yes, it'd need to be an entire new project. And the api as is is very jQuery like, we chose it to be consistent, but that would not need to be the case for a more general library, not even desired imo.
In conclusion this would mean:
- Fork the project, giving it a new name
- Implement a better api, one that isn't bound to jQuery style
- Add in automatic jQuery detection
- Also add back in jQuery style methods:
jQuery.cookie(key[, value, [, options]]),jQuery.removeCookie(key, [, options])
Additionally: Implement everything that was planned for version 2.0: RFC 6265 compliance, automatic JSON handling.
I haven't seen a client-side library that has RFC 6265 compliance, so that might be a selling point :). On the other hand, I have the feeling that cookies nowadays are a bit outdated in the first place and no one ever requested that particular feature. It is more like in the "doing things the right way" department.
For what it's worth, I think cookies are still quite useful - modern DOM storage is not available to the server and syncing data to be persisted on the server is overkill for many use cases.
On Mar 19, 2015, at 05:53, Klaus Hartl notifications@github.com wrote:
In conclusion this would mean:
Fork the project, giving it a new name
Implement a better api, one that isn't bound to jQuery style
Add in automatic jQuery detection
Also add back in jQuery style methods: jQuery.cookie(key[, value, [, options]]), jQuery.removeCookie(key, [, options])
Additionally: Implement everything that was planned for version 2.0: RFC 6265 compliance, automatic JSON handling.I haven't seen a client-side library that has RFC 6265 compliance, so that might be a selling point :). On the other hand, I have the feeling that cookies nowadays are a bit of outdated in the first place and no one ever requested that particular feature. It is more like in the doing things the right way departement.
—
Reply to this email directly or view it on GitHub.
@macgyver It is very useful to receive input like this, it serves as a reminder that this still might make the difference :O
@carhartl I was thinking more something like this:
- Fork the project in a small organization
- Remove jquery dependency
- Use that project as a dependency for this jquery-cookie project without changing the jquery-style API (or move the repository to the organization to enable github automatic redirect)
- Then in the future create specific projects porting the core to specific frameworks like angular
Then each project would have its own package manager namespace, its own project and jquery-cookie wouldn't change.
I would suggest trying to keep some backwards compatibility and don't just break everything, jquery-cookie can stay as is, it would just hold the namespace, not the core.
Makes even more sense!
I think I'm finally able to dedicate more time for this again, having finished building a house :)
Fiiiirst of all, we will need a name for the org...
js-cookie? :D
(then jquery-cookie, framework-cookie, etc.)
I mean js-cookie-dev for the org or something like that.
Example: https://github.com/jscs-dev
I think for the API structure the @Krinkle suggestion is the best approach. But by convention the initial capital letter is used for functions that should be instantiated using the new operator, so maybe window.cookie.set(), cookie.get(), cookie.remove() are the best alternative to comply with the localstorage and similar naming patterns.
@carhartl I created github.com/js-cookie organization to save the name and added you. I am not sure if this is the best name for it, you could create another one if you think of a better name.
I am willing to help on this.
Thanks a ton @FagnerMartinsBrack! I think that's great! 👍
@FagnerMartinsBrack I'm aware of that convention, but disagree this would violate that convention. It just means they're static methods of a class that is not publicly instantiable. The problem with cookie is imho that it's too generic and easily conflicting with random's people's legacy code, or poorly written user scripts / browser extensions that might have a global var cookie;.
I made a fast research to have some information in the usage:
window.cookie
- https://search.nerdydata.com/code/?and_code[]=window\.cookie&limit=0,20
- https://meanpath.com/f/HSGPlG
window.cookieStorage
- https://search.nerdydata.com/code/?and_code[]=window\.cookieStorage&limit=0,10
- https://meanpath.com/f/XVLVMF
var cookie
- https://meanpath.com/f/oMgoK4
- https://search.nerdydata.com/code/?and_code[]=%22var+cookie%22&limit=0,10
That is not too deterministic because one could use IIFE to wrap the window and obfuscate it through minification, declare the implicit global variable without var and without using the "use strict" statement, etc. but it helps to have an idea.
I couldn't find a way to get a case-sensitive result to check how likely var Cookie is in comparison with var cookie, but from the first results I could see that var cookie and window.cookie are indeed the most used namings (although window.Cookie is still used by a few sites).
The cookieStorage naming is practically null though and follows the localStorage, sessionStorage patterns (could this generate a conflict with some future standard?).
@Krinkle, @carhartl
What you think? Do you know a better way to check this in the wild?
I don't know of a better way.
But I think we could start out with the name cookie or Cookie and we will get some Feedback soon enough. Could we maybe provide a jQuery noConflict like mechanism, allowing to rename the global entirely? Too much effort?
Last not least, with modules, is this maybe not so much of a problem any longer?
I quite like cookieStorageI just realized. Would be really great if we then provide the same api as localStorage/sessionStorage, as mentioned.
Nice icon... :)
Google FTW xD
But I think we could start out with the name cookie or Cookie and we will get some Feedback soon enough. Could we maybe provide a jQuery noConflict like mechanism, allowing to rename the global entirely? Too much effort?
I started using Cookies, maybe that way we could avoid creating some mechanism to change the global: js-cookie/js-cookie@25ced9c
Last not least, with modules, is this maybe not so much of a problem any longer?
That might not be a problem if one uses modules, but simple websites have no reason to use any custom module system, it's too much overhead.
I quite like cookieStorageI just realized. Would be really great if we then provide the same api as localStorage/sessionStorage, as mentioned.
In the end "cookieStorage" may cause confusion because cookies has nothing to do with the HTML5 Storage API, it's not even standard, just an standalone API.
Fixed with: #360
How to expiring cookie to 12 hours ?
Thank
@jlucvs check this: #162 (comment)
Just to clarify:
js-cookie v1.5.0 and v1.5.1 are backwards compatible with the $.cookie API, but as from 1.5.0 the $.cookie API is deprecated.
js-cookie v2.0.0 and onwards does not expose the $.cookie API anymore, it will throw an error:
$.cookie is not a function
If you want to upgrade straight from the jquery-cookie repository without changing anything, just pick the version 1.5.1 until you are ready to upgrade to the latest version.
Please, read carefully the changelog for the version 2.0.0 before upgrading.
I wrote some examples on how to integrate js-cookie with AngularJS: js-cookie/js-cookie#103