Add ability to pass custom cookie string

[wintercounter]

I want to parse another site's document.cookie.

Example

const otherSiteCookies = new Cookie('mycookie=1')
otherSiteCookies.get('mycookie')

[carhartl]

If you have access to the cookie reading it given it’s name should just work. But that’s the problem, you do not habe access to cookies of other sites apart of your own. Only subdomains of your own domain may work, with an appropriate domain attribute.

So are you talking about subdomains here?

[wintercounter]

I'm having different iframes from different sites, (same domain, multiple subdomain). I'm accessing the iframe though contentDocument and I need to parse those cookies.

[carhartl]

Including js-cookie in those pages served by the iframes should give you the ability to retrieve these cookies, using Cookies.get('name').

If you have no control over these I‘m not sure how you could make use of the library. It all relies on a document.cookie of the current site. Maybe there was a way to bend the context (using with?) in the outer frame?

[carhartl]

Anyway, this seems to be more of a feature request, we might not need to look for workarounds.

[wintercounter]

I cannot include js-cookie there. I'm already having my working code but I'm parsing these cookies by hand and wanted a cookie parser library instead.

Yes, it's a feature request.

[carhartl]

You could use https://github.com/jshttp/cookie for parsing?

[wintercounter]

What I want to avoid is having multiple libraries in my bundle doing cookie parsing.

No offense but let me ask, why don't you use it also? :)

[carhartl]

why don't you use it also

It does a lot more things than we need and we strive for keeping this library as small as possible, and free of dependencies. For the same reasons it’s unlikely we’re going to implement this feature any time soon (unless suddenly a lot more people start asking for it). But since you asked for a “parser library” I thought that other one might be of help.

[FagnerMartinsBrack]

The lib is coupled to document.cookie. Decoupling the input mechanism from document.cookie to a string (while keeping document.cookie as the default) seems like a reasonable request. We've got the default converter logic that one might want to reuse for the input as a string.

However, right now js-cookie purpose is "A simple, lightweight JavaScript API for handling browser cookies". Focus on the "browser" part, which is supposed to imply a wrapper over document.cookie. It's not supposed to be used anywhere else other than the browser or any other environment that doesn't contain a window.document.

This discussion is less about introducing a feature, but fundamentally changing the purpose of the library for the intention to satisfy one use case.

I think we should wait for more requests like this with different use cases instead of jumping the gun and completely changing the purpose of the lib. However, in the meantime feel free to fork the project and extend for your own use case. Your feedback is definitely appreciated, for it helps to build up an idea of the interest on having different kinds of input parsing implemented.

Who knows, we might get it implemented in v4 :)

[FagnerMartinsBrack]

On a sidenote, @Krinkle does Wikipedia uses js-cookie on any of the bundles you specified in this post: https://phabricator.wikimedia.org/phame/live/7/post/175/wikipedia_s_javascript_initialisation_on_a_budget/

I remember you were active on jquery-cookie in the beginning.

It's interesting to understand the codebases at scale that use js-cookie and that are also impacted with the amount of "nice to have" features we add to the payload size.

[theodorejb]

@wintercounter Consider trying https://github.com/theodorejb/es-cookie. It has a native parse function which should do what you want, and it's pretty much be a drop-in replacement for js-cookie as long as you don't rely on custom converters.

[Krinkle]

@FagnerMartinsBrack Hi. Wikipedia still uses the older and simpler jquery-cookie script (source code) with a light wrapper for application-specific integration (source code).

I'm not aware of any additional features being needed for our use cases.

We have sometimes found performance regressions due to use of cookies in hot code paths. However were due to lower-level cost of reading or rewriting document.cookie, not with the JavaScript code we use to access it.

[FagnerMartinsBrack]

@carhartl Shall we close and wait to see if there will be more requests like this in the future? This is the first request of its kind that I remember.

In the meantime, I recommend to fork js-cookie and extract the parsing code yourself if somebody needs to use the parsing code.

[carhartl]

I recommend to fork js-cookie and extract the parsing code yourself if somebody needs to use the parsing code.

Which practically is, as mentioned, es-cookie.

Then there‘s #595, the outcome of which almost eliminated the amount of parsing work that‘s being done.

Closing..