-
Notifications
You must be signed in to change notification settings - Fork 8
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
Prefer flow #97
Comments
Aware I've opened quite a few suggestions, hoping to put some time aside to start implementing soon, assuming the approach in #64 is ok. |
@thewilkybarkid thank you so much, I'm sorry about leaving you hanging on #64, I haven't had a minute to review it, since schools are closed in Italy and this complicated my personal situation a bit 😩 I hope I'll find a minute soon! Thanks for the patience |
by the way, this specific suggestion may not be a safe refactor in 100% cases, due to type inference. I don't have a specific example to bring, but it happens in many cases that refactoring from The transform from For this reason, I'm not fully convinced about implementing this as a rule/fix, since it may lead to unwanted results. |
Absolutely no problem. Can commit some work time to have a crack at some of these, but don't just want to trigger the usual open-source problem of being demanding. 😅
It'd be interesting to find real cases where it is unsafe, and see if it's possible to exclude them... |
one case I remember (but I don't have time to reproduce fully right now) is when working with I've discussed this some time ago with @gcanti and I remember he being skeptical about this as well |
If the argument for a pipe is only referenced in the first step, it can be replaced with a
flow
:and
can be:
and
Can be easier to read, and keeps it out of scope for the rest of the pipeline.
Real examples
The text was updated successfully, but these errors were encountered: