Correction needed: "JavaScript Numbers are represented by IEEE 754 64-bit (double precision) floating point values, not fixed Decimal values. Because of this, some values (such as 0.3) are less precise as the fractional values used and whole numbers are only accurate to 2^52-1."
What this means is some bits (of 64) are for the whole number portion, and others are for the divisor.
For those curious, the "Dave's Garage" channel on YouTube went over the interesting history of this.
There are unfortunately some formatting issues... part of the HTML markup is posted twice, and the markdown code formatting towards the end seems to be entirely broken.
As to the content, it all seems relatively straight forward, until it breaks...
I do think it might have been better served by not introducing all the concepts in play at once... Starting with a very basic, single instance websocket server. Then explain the shortcomings and how sticky sessions are provided by socket.io, along with channels/routing. Then expressing the issues with connection scaling, and adding in cluster and the redis adapter. Why adding a worker on the server helps, etc.
Those last bits are actually questionable for the use case in question, as most bottlenecking will become IO bound on Redis, and cluster/worker may not add much as Node.js uses thread pooling for IO connections.
That said, by starting simple, and adding the extra bits, it becomes possible to separate some of the conceptual pieces that can overload someone not already familiar with those pieces and the why behind them. Also, a github repo that has commits on master matching the stages of the project would also be very beneficial.
While, mildly interesting, I don't think this can really be relied upon in practical terms. It might be nicer if this were a linting tool to ensure that public (exported) classes and methods are indeed documented, provide generated comments, and flag for review before it can pass linting (have to remove the @autogenerated tag).
In the end, I think AI developer assistants are going to become more common... been playing with the Github extension for VS Code, which I haven't had much use for, but it is interresting.
Nice to see zero dependencies... but would prefer to see more of these abstraction libraries over fetch (even if it means polyfilling, similar to early Promises/A). Recent node has it, the browser and deno have it. It just means more broad usage beyond just server-side node.
May look at it deeper in the future... at first glance, about the only thing of note is the DI library. While interesting, generally not a big fan of DI in JS/TS..
Been playing with Tauri + React for a personal project, it's definitely interesting, I haven't gotten much past what the article oovers so far, mostly in that I've been debating a bit on how/where to do some thing and my approach on the UI side vs React side.
Convert TypeScript enum to a string.
Note: I prefer just to use the object syntax, as a TS enum, since you can assign the value for the right-hand and don't get the often unexpected behavior of both forward/reverse indexes in the enum itself.
Also, aside: you can configure .Net MVC and other frameworks to deliver enums as text strings, to align behaviors better. I'm also a proponent of using the string values in databases as it provides better clarity imo. If you're using PostgreSQL it supports an enum type declaration for your table columns directly as a constraining usage in practice.
Or... you can use the ES2022 #privateMethod(){} definition, where the hash symbol is used. It's been practically available for some time now. https://caniuse.com/?search=private%20class%20fields