refactor: ♻️ add pipeline operator support #318
Conversation
|
|
||
| interface IEvent { | ||
| date: Date; | ||
| } | ||
|
|
||
| const viewTags = talk => (talk.tags ? talk.tags : []) | ||
|
|
||
| export let eventTags = pipe( |
There was a problem hiding this comment.
Interesting 🔥
But tt still seems to me that pipe(/***/) using is more informative. Maybe because |> operator is very new and rare for me.
There was a problem hiding this comment.
We should always strive for using native implementation of functions and methods etc.
🚀🚀🚀🚀
| uniq, | ||
| ) | ||
| export let eventTags = e => | ||
| e |> prop('talks') |> map(viewTags) |> flatten |> uniq |
There was a problem hiding this comment.
In my opinion, this repetition e => e |>... looks a bit strange, after pretty descriptive curried .pipe :)
There was a problem hiding this comment.
agree
here is proposal "composition" pipe
https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
There was a problem hiding this comment.
That is because rambda's pipe and native pipeline operator do different things, but use same name. So e.g. in Elm you have two options: composition using << operatior and create pipelines using |> operator. Through my humble experience in elm, I learn that it is better use pipeline operator when we need the value now (e.g. in render function in react), because it doesn't support delayed evaluation. In this case it reads super awesome.
As for composition operator - I think it is clear, that it should be used for creating helper functions as in your example.
There was a problem hiding this comment.
Also in ReasonML doesn't support composition, and only pipelines. JFYI.
Feels unnatural from the very beginning. But used to it almost instantly
No description provided.