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

return promise #11

Merged
merged 1 commit into from
Nov 15, 2017
Merged

return promise #11

merged 1 commit into from
Nov 15, 2017

Conversation

ShallmentMo
Copy link

It will be much nicer if we can return a promise, so that we can do some UI stuff after the file is downloaded.

Copy link
Owner

@egeriis egeriis left a comment

Choose a reason for hiding this comment

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

Great idea! Just one comment on the PR.

src/zipcelx.js Outdated
@@ -17,7 +17,7 @@ export const generateXMLWorksheet = (rows) => {

export default (config) => {
if (!validator(config)) {
return;
return undefined;
Copy link
Owner

Choose a reason for hiding this comment

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

This is implicit without return value.

Copy link
Author

Choose a reason for hiding this comment

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

line 33 will trigger expected no return value consistent-return eslint error if I don't return undefined. I don't have any better idea about this.

Copy link
Owner

Choose a reason for hiding this comment

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

Oh, right. Good point. Considering that this statement is here because a validation failed, I think it would be most suitable to simply throw an error then.

Copy link
Author

Choose a reason for hiding this comment

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

Throwing an error might not be expected. I think a rejected promise will be better. But it need to change the validator implement. What do you think?

Copy link
Owner

Choose a reason for hiding this comment

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

I think it's hard to find a proper solution without breaking the API. But considering that we are making a could-be breaking change, by suddenly returning from this function, we can just as well throw an error.

In your current implementation, either undefined or Promise is returned. I think it's actually better if either error is thrown or Promise is returned. Then the consumer doesn't have to check for returned value type, but can simply wrap call in catch-try block.

Copy link
Author

Choose a reason for hiding this comment

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

Done. Please check

@egeriis
Copy link
Owner

egeriis commented Nov 14, 2017

@ShallmentMo Thanks. I'll merge in a moment.

@egeriis egeriis merged commit 53f441f into egeriis:master Nov 15, 2017
@ShallmentMo ShallmentMo deleted the return-promise branch December 20, 2018 15:25
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.

2 participants