| 00:02 | <rbuckton> | I think that's the point of the |> ... operator? x |> ...[a, b, c] is essentially x |> a(^) |> b(^) |> c(^). |
| 00:03 | <rbuckton> | It would possibly be better written as getCustomerNameSteps = [...] |
| 00:04 | <rbuckton> | Also, this would be impossible for a type system like TypeScript to statically type in any meaningful way. You'd have to wait for the |> ... to instantiate generics, meaning you have no type inference when composing functions in the array. |
| 15:27 | <TabAtkins> | Right, but my point is, carrying around an array of functions instead of just composing them into a single function is odd. If they did that, then it would just be |> getCustomerName(^^) |> and be a completely uninteresting example. |
| 15:28 | <TabAtkins> | It just so happens that, if you're using pipe(), carrying around an array can be somewhat ergonomic since you can then spread the functions into the arglist. But that's an accidental quality of the features and syntaxes involved; it's not intended as something that should work. |
| 15:28 | <TabAtkins> | But even with pipe(), using a composed function instead of an array is likely better since then you can use it elsewhere, rather than just in pipe(). |
| 15:30 | <TabAtkins> | It just seems odd that this particular behavior is being defended on FP grounds, when it is actually a pretty weird and not particularly FP-ish thing to do. Good FP programming would use actual function composition. |