Skip to content
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

add allThen function #3165

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

add allThen function #3165

wants to merge 3 commits into from

Conversation

HoKangInfo
Copy link
Contributor

use Promise.all after ap, raise error #3157
add allThen function, simplify Promise.all.bind(Promise).

Copy link
Member

@CrossEye CrossEye left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although this is a clearly useful function (and, I might add, a nicely done pull request), I'm very hesitant to add this.

The Ramda team has repeatedly expressed its reservation about Promises. Most of the reasons are captured in Broken Promises -- but the biggest one is that they are so close to lawful abstract types such as Functor and Chain, but they blow it, which means that you have to be very careful when trying to use them with generic code.

So Ramda has managed to reduce its direct support for Promises to only the two functions andThen and otherwise. It's not that Promises don't work with Ramda code, just that Ramda does not go out of its way to work with them. This makes me really hesitant to increase that support.

So although this review suggests that changes are needed, I would suggest holding off on them until and unless you first convince us that it's worth offering any additional Promise support, especially when this is trivial for users to write as

const allThen = (fn) => (ps) => Promise. all (ps) .then (fn)

* R.of,
* R.ap([p1, p2]),
* R.allThen(R.join('|')) // => 'test1|test2'
* );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although we're not entirely consistent with this, I think it's better if our examples rarely use any Ramda functions outside the one being demonstrated. While join is probably clear to most readers, both of and ap might cause confusion.

Perhaps better would be something like this:

R .allThen (xs => xs .join ('|')) ([Promise .resolve ('foo'), Promise .resolve ('bar')])
  .then (console .log) //~> "foo|bar"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, it's really more concise.

var allThen = _curry2(function allThen(f, ps) {
if (Promise == null || !_isFunction(Promise.all)) {
throw new TypeError('Promise is not defined');
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll be glad when we can stop doing these tests!


if (!(_isString(ps) || _isArrayLike(ps) || _isIterator(ps))) {
ps = _of(ps);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ramda usually strives for simplicity. I don't think allowing for either scalars or arrays really fits.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this will cause confusion, but It's more convenient, determine whether to use andThen.
I will remove it.

@CrossEye
Copy link
Member

@HoKangInfo:

Do you want to argue in favor of this? Or can we just go ahead and close it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants