Hey, I'm the author of the linked article, cool to see this is still getting passed around.
Definitely agree there's no perfect solution. There's some escaping that seems to work ok, but that's going to break CSV-imports.
An imperfect solutions is that applications should be designed with task-driven UIs so that they know the intended purpose of a CSV export and can make the decision to escape/not escape then. Libraries can help drive this by designing their interfaces in a similar manner. Something like `export_csv_for_eventual_import()`, `export_csv_for_spreadsheet_viewing()`.
Another imperfect solution would be to ... ugh...generate exports in Excel format rather than CSV. I know, I know, but it does solve the problem.
Or we could just get everyone in the world to switch to emacs csv-mode as a csv viewer. I'm down with that as well.
Appreciate your work! Your piece was pivotal in changing my mind about whether this should be considered in our purview to address.
The intention-based philosophy of all this makes a lot of sense, was eye opening, and I agree it should be the first approach. Unfortunately after considering our use cases, we quickly realized that we'd have no way of knowing how customers intend to use the csv exports they've requested - we've talked to some of them and it's a mix. We could approach things case by case but we really just want a setup which works well 99% of the time and mitigates known risk. We settled on the prefixing approach and have yet to receive any complaints about it, specifically using a space character with the mind that something unobtrusive (eg. easily strippable) but also visible, would be best - to avoid quirks stemming from something completely hidden.
Thank again for your writing and thoughts, like I said above I haven't found much else of quality on the topic.
There was no form submission, I'm not sure where you got that. There was also no POST. Though yes, I agree that in the core HTTP semantic, you wouldn't want to change state on a GET and that should include not calling `Set-Cookie`. And yet the reality is that that nearly every application - and many popular libraries like auth0 - do in fact set and clear cookies on `GET`.
The issue here was that the `Link` component in NextJs
- does preloading by default (which is a bad idea exactly for the above reason of reality being different from theory)
- doesn't do preloading by default when running on the dev server (so you don't see the error until its deployed)
- because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used
Everything else was the wild goose chase bits.
Also I asked claude to criticize the article as a web forum might before publishing, and this is definitely the tone it gave :D
Oh, also, I'm pretty sure I got the part wrong where i was talking about the preload attribute in HTML, but so far no one's noticed. I should correct that.
Ah, yes, I mean, agree that would have been technically correct, but like I said, its just not how a lot of the web works. auth0-nextjs seems to react to `GET` by default (though it might also work with `POST` and you certainly can override things)
So OP was correct that a proper use of the foundational layer of HTTP would have saved time, yours in particular, right?
Also, I didn’t get your ”Claude predicted your tone smiley” thing. OP tone seemed polite and clear. Your tone, on the other hand, seemed defensive and dismissive. Even after you realizing that you initially misunderstood what OP said, adding a “I mean” and a “but I like I said” to reinforce you were right even while misreading what OP said (rather than just acknowledging you got it wrong in the first reading).
I would go even further and speculate that you were predisposed to get a dismissive tone from a web forum (your previous Claude test suggests that) so much that you got a perfectly fine comment and misread in a way that it felt in the “wrong tone” to you. Even misunderstanding what the post said. All of that to confirm your predisposition.
I think I left my context collapse a little here. The article had gotten really good feedback when I passed it around in the various communities I'm in, but I hadn't written it with the idea of the broader hackersphere in mind. I did post the story to here, but I didn't really think it would get traction. I should have done some double-checking and added caveats and context beforehand.
My comment about Claude was simply intended to giggle at how much it has us pegged, not to call out the op directly.
By electing to actionably mutate state on GET, one subscribes themselves to a world of hurt.
It is totally how the web works, both as defined by HTTP and in practice. Surely one can pile a dozen workarounds to circumvent the GET safety definition, but then it's just flat out simpler to have it be a POST or DELETE and work as intended.
That a lot of people are doing it a certain - broken - way certainly does not mean they are right.
That would also have been practically correct, avoiding you this bug and the many hours of debugging, being resilient to byzantine/adversarial technologies (NextJS reimplementing prefetching itself and making debugging very difficult)
"because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used"
I may be wrong, but I don't think using JavaScript vs using the standard HTML <link> element to prefetch makes a difference here. I don't see anything in the HTML specs about preload or prefetch delaying cookie setting to sometime after the resource is actually loaded (although admittedly I find this bit of the spec somewhat hard to read, as it's dense with references to other parts of the spec). I tried it out, and, both Firefox and Chrome set the cookies for preloaded and prefetched links when the resource is loaded, even if the resource is never actually used.
Interesting post with a few neat things I didn't know (spread on an object? Very cool)
But then you still have. To deal with awesome functional helpers like denounce, not to mention insanely useful things like cloneDeep and zipObject. Instead I'd note to use the natives tuff wherever possible and use lodash to pull in just the functions you need piecemeal.
Oh and you should certainly mention Function.prototype.reduce and Object.assign
Fantastic, now what if your domain model actually requires an underscore in things? Or more realistically umm ... ooh ... I dunno, how about I want to write some infrastructure, that iterates over objects? Surely, that's not a thing we use literally all the time. But hey, just write the code to filter out underscores.
Oh wait, now I'm passing my object to a third party library that preforms infrastructure? I guess they better provide a hook that I can inject my own naming conventions.
Yes, underscore fields work, until they don't. Is a function that returns an object really that hard for beginners? I can answer that as I actually teach beginners - yes, it's hard for like two class sessions, after the third homework assignment they have no other issues. So yeah, closures are the way to solve this.
I wouldn't use what this article proposes unless I definitely needed classes, but for the 1% of the time that I do this is a pretty nifty solution to one of my biggest gripes.
