30 karma · joined April 15, 2015
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.
My comment about Claude was simply intended to giggle at how much it has us pegged, not to call out the op directly.
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.
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
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.