Rename library to Cookie

[CupOfTea696]

It makes more sense to name the library after the singular name rather than the plural I think. You could add an alias for Cookies but mark it as deprecated, and then remove it in the next major release.

[FagnerMartinsBrack]

When you get() something you get the value from the collection of cookies that is abstracted into the Cookies namespace. You don't get from a single cookie, you get the value of a single cookie after inspecting the collection, that is why Cookie alone doesn't make much sense.

Is there a specific reason of why you would want a Cookie namespace, is that because of conflict? If it is, then you can use the .noConflict() feature.

[FagnerMartinsBrack]

Initially we thought on using cookie or Cookie to follow the $.cookie pattern, but then when I opened the original PR I wrote the Cookie with an ending s because we were not working with a single cookie after all. Nobody complained about that at the time so I assumed it was ok. The main point was not getting clashes with common names, such as cookie, so I was not willing to bikeshed on this too much.

Since the ship has sailed already, we will need a much stronger argument to change it. I don't see any value in deprecating the current name in favor of a singular.

[FagnerMartinsBrack]

Closing due to the lack of feedback from the OP. If you want to continue the discussion, please comment here mentioning one of the collaborators.

[CupOfTea696]

@FagnerMartinsBrack from an MVC standpoint, and seeing the Cookies library as a Model, it's usually the standard to use singular, that's why I was suggesting it. Also, sorry for the late reply but have been very busy last week.

[CupOfTea696]

If you decide on doing this it might indeed make sense to require a parameter for get and add an all method for retrieving all cookies.

[FagnerMartinsBrack]

... from an MVC standpoint, and seeing the Cookies library as a Model ...

js-cookie should be environment agnostic. There are projects that uses js-cookie and are not MVC based. Therefore there is no reason for changing the API to make it fit for a specific use case.

We want to create a library that is simple enough so that it can fir any use case.

... it's usually the standard to use singular, that's why I was suggesting it

There is no such standard.

Even if we develop this library using MVC in mind, there is no difference between having Cookies or Cookie. Both names as a model are legit, because MVC does not care about how the components are named, only the separation of Model, Controller and View.

[CupOfTea696]

js-cookie should be environment agnostic.

Yes of course, but the library does look and behave like a Model would in an MVC app though. Get and set methods and the like.

There is no such standard.

Never seen an MVC app use plural for Model names tho.

Again, this is just my opinion and a suggestion. In the end it doesn't really matter if a library is called a or b. This just seems to make more sense to me (personally) and thought I'd explain where I'm coming from.

[FagnerMartinsBrack]

... the library does look and behave like a Model would in an MVC app though. Get and set methods and the like.

The "Model" part in MVC is not about get and set, in fact there is no such standard on how to build Models, the pattern is totally paradigm and code style agnostic, it just dictates how to structure the code in a high level. Models are about business logic. If you are using an object oriented approach, then the Model will usually contain the objects that form your domain. If you are also using a functional approach, your model will contain the functions that form the behavior of your domain. If you are using aspect, your model will contain information of how certain parts behave.

There is no such thing as "MVC is get and set". The only thing I can think of when I hear get and set are anemic models. js-cookie is not that though, it doesn't play towards any specific way of doing things. Cookies might seems to be an object, but it is just a namespace for functions that can be treated either as an object or a composite of non-pure functions. get and set are not about CRUD, it is about operations on the cookie storage of the browser. It is just get and set because the names are self documenting, not because it represents an object oriented model built using MVC.

Never seen an MVC app use plural for Model names tho.

Just because some MVCs apps doesn't use plural in the file names, it doesn't mean that all MVCs apps use plural. It all depends on how the code is structured.

Again, this is just my opinion and a suggestion. In the end it doesn't really matter if a library is called a or b. This just seems to make more sense to me (personally) and thought I'd explain where I'm coming from.

I understand, and thanks for initiating the discussion.