-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
If you're doing a series of mutations specific to a custom type in that fashion, then there isn't much benefit. But imagine you want to chain operations on an existing type, whether it's a built-in like String, or a type introduced by a different package like sqlite.Database. To use method chaining you'd have to monkey-patch them, which can lead to all sorts of problems: colliding with other packages that want to monkey-patch the same types, confusing the reader when unfamiliar and seemingly undocumented methods appear (why does the SQLite documentation not mention this sqlite.Database#drop method? Which of my installed packages added that? ), your package breaking when the thing you're monkey-patching changes its API, altering object iterations, etc. The troubles with Prototype.js and MooTools in the '00s showed some of the headaches monkey-patching can lead to when it comes to JS especially, where users expect ever-changing browsers to work with 25-year-old code. (I still support changing flatten to smoosh, though.) You might subclass the existing type or encapsulate it in a new type, but then you're potentially breaking the user's typechecking, preventing the use of any other packages that want to do the same thing, escaping tree shaking, and becoming incompatible with unexpected types (what if the user already subclassed sqlite.Database themselves, and want to apply your transformation to that?).
Updated my comment above - you can also read the article in the source on GH: https://github.com/lmiller1990/lachlan-miller.me/blob/master/markdown/esnext-pipelines.md