3 ms·
> enum has long been panned by most users). Same with namespace Why? Would you would rather do a smurf naming convention than having your consts, DTOs, events,
by nsonha 1y ago
> enum has long been panned by most users). Same with namespace
Why? Would you would rather do a smurf naming convention than having your consts, DTOs, events, errors and what not neatly organized under the name of the function that uses it?
- WorldMaker 1y agoYou don't need to do a smurf naming convention if everything is modules (especially ESM). TS Namespaces are a hack from the time when everything was global scoped, but ESM has been around since ES2015, is supported out of the box in all major browsers today, and is supported in Node (I recommend "type": "module" in package.json) and preferred/native in Deno and Bun.
- nsonha 1y agoI find it's rather annoying that I specifically made the point that namespace allows grouping things and you just "psst have you heard of ...modules"? Just create a new file for every group of thing? That's nice, do you create a new file for every function and all its options and error types?
- WorldMaker 1y agoYes, if that's the organization structure that makes the most sense for that project. Arguably that's the most common React organization pattern going a long way back whenever Components are functions you generally have one function per file, plus a bunch of extra types for options/error types.
- nsonha 1y agonot all code is a React component. And enforcing one component per file is just gonna encourage bloated components (because who likes heaps of tiny files?). I would not cite every front-end convention as an inspiration for sensible engineering.