Remove jQuery dependency requirement?

[FagnerMartinsBrack]

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]

👍

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]

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

[FagnerMartinsBrack]

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]

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]

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]

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]

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

Makes even more sense!

[carhartl]

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]

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