Maybe I didn't get something bug I feel like the base issues could have been solved in an extremely easier fashion by not using class-based OOP
All methods have to be inside the class (or inside a common abstract class for ADTs)
No, just use functions
Once a class is defined adding methods to it from the outside requires module augmentation and unsafe mutation of object prototypes
No, just use functions
Worst of all, none of it can be optimized from a tree shaking perspective, so you'll end up with a huge bundle size that becomes prohibitive at a certain point
No, just put the functions in different files
The current "solution" that the FP community has adopted is the use of pipeable APIs.
“reactive” libraries like rxjs are event systems. Because they have a disconnect between the data being sent, and overhead for subscribing/unsubscribing, I wouldn’t consider them anything related to fluent design patterns.
I personally prefer pure functions, and changing state at the very last pop of the call stack (firsr method that calls pure functions is responsible for setting state, no where else can set state). Similar to fluent, but without the overhead of returning a new object. And easier to debug what is going on (fluent can turn into a finite state machine).
Fluent here refers to a style of API not the design pattern and has nothing to do with mutating state, the IO example above is 100% pure and functional in every possible interpretation.
"No, just use functions" => this is in the context of wanting a fluent api, if you want a fluent API plain functions are of no help.
"No, just put the functions in different files" => by the way this is 100% irrelevant for tree shaking, you can put all the functions in the same file and the result is the same (actually even better in size terms because you have less modules).
"No, some people just use functions" => yes people like me use just functions, but they also know what a function actually is.
So when programming a user needs to know exactly which module to import, exactly which functions are constructors of the datatype and which are methods for the datatype, and exactly how to use them.
That I really don't understand. I'm not familiar with IO or Effect but for example in lodash when I wanna use cloneDeep I'll just do import cloneDeep from 'lodash/cloneDeep';, yeah I have to know which module to import but it's not giving me a headache. Also there's no constructors and no additional methods, and the use is evident. So I don't see any case where a similar lib would cause these issues
Sure you can use directly lodash and direct imports, the problem becomes more apparent when using libraries that cover a bit more surface compared to lodash (like Effect, like fp-ts, etc) and in many codebases that translates to a large set of namespace imports import * as F, when using F you have everything inside and discoverability is problematic. For example only the Effect module in effect-ts provides 1000+ functions inside (they are all as you say "just functions") but you have to know what the "just functions" do, i.e. is the function constructing an effect or is a function combining? i.e. map combines, succeed creates
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Maybe I didn't get something bug I feel like the base issues could have been solved in an extremely easier fashion by not using class-based OOP
No, just use functions
No, just use functions
No, just put the functions in different files
No, some people just use functions
both RxJS and fp-ts uses pipeable functions. pipeable functions are as you say "just functions", the same way extension methods are "just functions"
“reactive” libraries like rxjs are event systems. Because they have a disconnect between the data being sent, and overhead for subscribing/unsubscribing, I wouldn’t consider them anything related to fluent design patterns.
I personally prefer pure functions, and changing state at the very last pop of the call stack (firsr method that calls pure functions is responsible for setting state, no where else can set state). Similar to fluent, but without the overhead of returning a new object. And easier to debug what is going on (fluent can turn into a finite state machine).
Fluent here refers to a style of API not the design pattern and has nothing to do with mutating state, the IO example above is 100% pure and functional in every possible interpretation.
Use Nim programming language and you don't care whether it's a method or function
You write whatever Style you want
Big part of the project is to create something both really nice and with great interop with the wider ts ecosystem it's not only about style :)
"No, just use functions" => this is in the context of wanting a fluent api, if you want a fluent API plain functions are of no help.
"No, just put the functions in different files" => by the way this is 100% irrelevant for tree shaking, you can put all the functions in the same file and the result is the same (actually even better in size terms because you have less modules).
"No, some people just use functions" => yes people like me use just functions, but they also know what a function actually is.
That I really don't understand. I'm not familiar with IO or Effect but for example in lodash when I wanna use
cloneDeepI'll just doimport cloneDeep from 'lodash/cloneDeep';, yeah I have to know which module to import but it's not giving me a headache. Also there's no constructors and no additional methods, and the use is evident. So I don't see any case where a similar lib would cause these issuesSure you can use directly lodash and direct imports, the problem becomes more apparent when using libraries that cover a bit more surface compared to lodash (like Effect, like fp-ts, etc) and in many codebases that translates to a large set of namespace imports
import * as F, when usingFyou have everything inside and discoverability is problematic. For example only the Effect module in effect-ts provides 1000+ functions inside (they are all as you say "just functions") but you have to know what the "just functions" do, i.e. is the function constructing an effect or is a function combining? i.e.mapcombines,succeedcreates