This repository has been archived by the owner. It is now read-only.

Remove jQuery dependency requirement? #349

Closed
FagnerMartinsBrack opened this Issue Feb 10, 2015 · 25 comments

Comments

5 participants
@FagnerMartinsBrack
Collaborator

FagnerMartinsBrack commented Feb 10, 2015

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?

@Krinkle

This comment has been minimized.

Contributor

Krinkle commented Feb 10, 2015

👍

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.

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 18, 2015

I'm open to this, though we'd need a new name for this whole thing I guess :)

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 18, 2015

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.

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 18, 2015

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.

@carhartl carhartl removed 2.0 feature labels Mar 18, 2015

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 19, 2015

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.

@macgyver

This comment has been minimized.

macgyver commented Mar 19, 2015

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.

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 19, 2015

@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.

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 19, 2015

Makes even more sense!

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 19, 2015

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...

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 19, 2015

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

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 19, 2015

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.

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 19, 2015

@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.

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 19, 2015

Thanks a ton @FagnerMartinsBrack! I think that's great! 👍

@Krinkle

This comment has been minimized.

Contributor

Krinkle commented Mar 19, 2015

@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;.

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 19, 2015

I made a fast research to have some information in the usage:

window.cookie

window.cookieStorage

var cookie

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?

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 21, 2015

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?

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 21, 2015

I quite like cookieStorageI just realized. Would be really great if we then provide the same api as localStorage/sessionStorage, as mentioned.

@carhartl

This comment has been minimized.

Owner

carhartl commented Mar 23, 2015

Nice icon... :)

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 23, 2015

Google FTW xD

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Mar 30, 2015

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.

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Apr 9, 2015

Fixed with: #360

@jlucvs

This comment has been minimized.

jlucvs commented May 14, 2015

How to expiring cookie to 12 hours ?
Thank

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented May 14, 2015

@jlucvs check this: #162 (comment)

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Jun 29, 2015

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.

@FagnerMartinsBrack

This comment has been minimized.

Collaborator

FagnerMartinsBrack commented Oct 10, 2015

I wrote some examples on how to integrate js-cookie with AngularJS: js-cookie/js-cookie#103

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