-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: ♻️ add pipeline operator support #318
base: master
Are you sure you want to change the base?
Conversation
|
||
interface IEvent { | ||
date: Date; | ||
} | ||
|
||
const viewTags = talk => (talk.tags ? talk.tags : []) | ||
|
||
export let eventTags = pipe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, this repetition e => e |>...
looks a bit strange, after pretty descriptive curried .pipe
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree
here is proposal "composition" pipe
https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.