This got me thinking about what the existing cookie libraries looked like in npm, since I figured it was a solved problem already, potentially even with the exact same API.
There are a lot of cookie libraries for the browser in npm! Here are the ones I found, grouped by what syntax they end up implementing, and showing their current downloads per month...
I think it's a good example of npm's problem as a search engine for packages. Realistically all of these libraries have the same goal, and probably achieve it equally well. A few have better browser support, a few have better docs, a few have better tests, etc.
No one should be prevented from creating and publishing whatever they want as a library.
But npm should be doing a much, much, much better job at pointing people towards the popular libraries. It takes a lot of work to figure out what cookie libraries to use. Or what snake-case library to use. When it really shouldn't. You could easily eliminate most of these libraries with a few simple metadata checks. And I think it's incredibly unfortunate that npm isn't pushing people in that direction.
I think you raise a good point, but when has this been the package manager's concern?
When I type in 'dnf search' or 'apt-get install' or 'pip search' or the equivalent, I don't get details, I just get a list of packages, one of whose title or description fields match what I pass on the command-line. A package's exported API is important (obviously, since without it you can't use it), but I'm not entirely sure the package manager is the best place to surface this information. Or maybe it should be, but no package manager so far does this well?
Yup, I don't think any package manager has ever really done this well.
But what makes the problem worse is that npm advocates using lots of small modules, and using them in an environment (the browser) where duplication weight has big negative consequences.
I think there's a real opportunity to unseat npm if someone applied to same kind of UX-first thinking to package management that has been applied to other areas.
I kind of agree.. the search on npm isn't very good, I get better from google with site: option. Beyond that, it would be nice if results could be sorted by downloads/month, freshness, frequency of updates, and github issues.
Even just downloads/month on the search results screen would be helpful, as well as repo link... I usually look at downloads and gh issues as the canary for health, which is usually a good indicator.
It's absolute garbage. More than once I've not been able to search for a package with the exact spelling. Google usually guides me to the page, or manually manipulating the URL.
Fair enough, I didn't like it and that's the main reason why I continued and published this package. Is it just a preference or do you have any reasoning for liking it?
It is totally a valid reason, that's what I wanted to say with fair enough (:
I see, you could just call the same function few times with different options (preferred) as cookies(cookie1, opt1); cookies(cookie2, opt2); or concatenate them: cookies(cookie1, opt1)(cookie2, opt2); but this is arguably really strange syntax.
I will add more examples to the readme.md to make it more clear :+1:
To me it's silly that bower requires npm.. so just use npm. Although you may or may not agree with npm's dependency resolution, I find it more silly to use a tool that requires another tool that does the same job...
I prefer my screwdriver, that I have to open with another screwdriver.
Precisely that. To in-the-loop JS developers, Bower is old news. To see Bower/Less/jQuery in 2016 conjures up images of out of touch backend developers living in 2011.
There are better alternatives available (NPM/PostCSS/vanilla.js to the above)
Anyway, I didn't really intend this library to be in-the-loop. I just did it because I couldn't find one I liked in 2016. Which is just nuts on itself. so I went all old-school and tried to keep cross-browser support high and make it simple. It took an hour to be done and a couple of them to test and document it (plus another couple of them for small details such as CDN, bugs/patchs/small features).
jQuery to me has the same connotations but I was surprised by Bower. As an out-of-the-loop sometime JS developer what's respectable these days, npm/gulp/sass, vanilla.js/react/angular2?
Per RFC 6265, which is the cookie spec you seem to use, the valid chars for cookie names is defined [1] by RFC 2616 (since obsoleted by the 723x series; but agreeing on this issue [2]).
The cookie name must be a 'token', which is incidentally the exact same rule as for HTTP header names. 'token' evaluates to one or more of the following ASCII visible characters:
Right now you allow any valid JSON object key to be set as a cookie name.
EDIT: To be more precise, your defaults are fine as they URLencode the key too, along with the value. But the defaults are overridable and affect both the cookie key and value simultaneously. Allowing the value encoding to be overridden would be useful, while allowing the name encoding to be overridden can cause the cookie to fall out of spec.
I see, so I could add a `cookies.encodevalue()` and default it to `cookies.encode`. However, I think that'd just add too much noise to it so I will just add a warning. Thank you.
Yes, after the initial simple version, when I thought of expanding it, I looked into js-cookie and Cookies [1], but they all seem to require a `.set()` and `.get()` methods which I find too verbose for something so simple. A couple more of differences:
- I just added a CDN to cookies.js
- The default is a 100-day cookie, as cookies for me imply long-lived cookies, not sessions.
- The default is that if you visit `https`, it will require secure connection.
- [configurable] to remove a cookie you can just null-ify it.
Someone already mentioned js-cookie [0], but they didn't mention that it supports legacy browsers! If you're tied down supporting old IE, it's a great choice.
I've used both js-cookie and cookies-js, and ultimately ended up going with js-cookie. Unfortunately, I don't remember the reason why js-cookie won me over; I think I encountered some issue with cookies-js.
Obligatory old man rant/question... why does software development need to be delightful? I just need it to work and not get in my way. I have other things I can do in my life that are delightful, like reading a good book or watching my kid's first steps.
Edit: I'm sorry, that came off with a lot extra snark and not nearly as much joking as I was intending. I'm happy that people find working with cookies delightful.
That was totally my original meaning; sensible defaults, easy options and just a simple function to work with makes me want to keep using a library all day. So I try to follow that when writing a new library when I'm not comfortable with the status quo.
Maybe you just defined delightfulness? Things that just work and not get in my way are few enough and far enough between that when it happens, I'm always delighted! ;)
That is great that you have a work life balance you are comfortable with but why not enjoy working? Given the choice of getting paid to do something delightful vs doing something that just works but not super enjoyable, I pick delightful. I don't know that anyone ever said it needed to be delightful but there are enough people who would prefer it that way.
It was intended more as a playful[1] comment on the overuse of the word "delightful", "beautiful", etc. Hence the sarcastic lead in with the ellipses on the end. I'm happy that some people can get that from coding.
[1] well that was the intention, obviously it didn't come off that way.
cookies({ token: '42' }, {
expires: 100 * 24 * 3600, // The time to expire in seconds
domain: false, // The domain for the cookie
path: '/', // The path for the cookie
secure: https ? true : false // Require the use of https
});
Why? It looks pretty standard to me. It uses named variables for options, instead of argument position, and has reasonable defaults, so you don't have to specify every option.
This is the standard, modern way of added options to a function.
There are situations where cookies make more sense. Local storage gives you less control on the origin where that data can be accessed. Local storage doesn't let you set things such has HttpOnly so that JavaScript can not access the data (this is important to limit the risk of XSS when dealing with session ids). Local storage also doesn't give you as much control over when data should expire.
Sure but here we're talking about javascript cookies that aren't htttpOnly or secure. The expiration date and broad compatibility are the only arguments for the use of js cookies.
This got me thinking about what the existing cookie libraries looked like in npm, since I figured it was a solved problem already, potentially even with the exact same API.
There are a lot of cookie libraries for the browser in npm! Here are the ones I found, grouped by what syntax they end up implementing, and showing their current downloads per month...
Using the .get() .set() .remove() syntax:
Using the Web Storage syntax: Using the almost-Web-Storage syntax: Using the `(get, set) syntax: Using your syntax: I think it's a good example of npm's problem as a search engine for packages. Realistically all of these libraries have the same goal, and probably achieve it equally well. A few have better browser support, a few have better docs, a few have better tests, etc.No one should be prevented from creating and publishing whatever they want as a library.
But npm should be doing a much, much, much better job at pointing people towards the popular libraries. It takes a lot of work to figure out what cookie libraries to use. Or what snake-case library to use. When it really shouldn't. You could easily eliminate most of these libraries with a few simple metadata checks. And I think it's incredibly unfortunate that npm isn't pushing people in that direction.