Remix.run Logo
teaearlgraycold 5 days ago

Using the path field is a code smell

NBJack 5 days ago | parent | next [-]

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

kijin 4 days ago | parent | next [-]

It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages.

For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now the cookie at /cart conflicts with the one at /cart/checkout because each page has its own cookie.

oneeyedpigeon 4 days ago | parent | next [-]

If you want cookies to be global, set them to / or leave out the path. If you want more fine-grained cookies, use a specific path. What's the problem? Currency is—in your example—clearly a site-wide setting. I think sites should make more of their hierarchical structure, not less.

kijin 4 days ago | parent [-]

If you leave out the path, it will default to the directory of the current URL, not /.

If not for this default behavior, it would have been much easier to manage global settings such as currency. Right now, all it takes is one cookie without a path to introduce inconsistency, only on some pages, in a way that's hard to reproduce.

foldr 4 days ago | parent | prev [-]

Isn't that just the feature working as intended? Of course it is possible to introduce a bug by setting or not setting a cookie somewhere where it should/shouldn't be set.

I've never found a use for path-based cookies personally, but I'm not sure this is a particularly compelling example.

speleding 4 days ago | parent [-]

The typical example of a path-based cookie is the "remember my login name" feature, where you want the cookie with the user name only available on the login page. (And you cannot use session storage because you want it to work whilst logged out.)

Xelynega 4 days ago | parent [-]

You don't need to store multiple login names for seperate pages though, so why can't this just be a site wide cookie?

speleding 4 days ago | parent [-]

That would include the cookie with each request, which is inefficient. And potentially it also can get sent with requests to other subdomains, which may not be desirable from a security point of view (it could be cdn.example.com, owned by someone else)

teaearlgraycold 5 days ago | parent | prev [-]

For modern applications you’ll have better ways to maintain state. As shown they cause trouble in practice. Cookies should be used sparingly.

prokopton 5 days ago | parent [-]

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

bpicolo 5 days ago | parent [-]

Server can store session state

telgareith 5 days ago | parent [-]

Server side session state for more than authentication is way worse than "code smell."

It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!

naasking 4 days ago | parent | next [-]

You just described how the whole web operates. It works just fine.

MBCook 4 days ago | parent [-]

Even if you want client side, we have better ways now than cookies.

inopinatus 4 days ago | parent [-]

We do, but only cookies are universally available. Plenty of unusual user-agents in the world, or people like me that browse with JS off by default.

CrimsonRain 4 days ago | parent | prev [-]

I add some products in phone. Then I login to desktop later for modification and order. Cart is empty. That's engineering smell. A really bad one.

telgareith 4 days ago | parent [-]

Thats nothing more than UX/UI.

> In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

- https://en.wikipedia.org/wiki/Code_smell

tacone 3 days ago | parent | prev [-]

I am using path to wire my http only cookies to be sent only to /api not in assets/html requests. The cookie will eventually contain a JWT token I do use as an access token. Consequently I will probably wire my refresh cookie only to be sent to /api/refresh-token and not in other requests.

The client won't get to decide which cookie to send where.

Looks like a good pattern to me.