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

callAction has a bad condition | bug #444

Open
seeden opened this issue May 20, 2016 · 8 comments
Open

callAction has a bad condition | bug #444

seeden opened this issue May 20, 2016 · 8 comments

Comments

@seeden
Copy link

seeden commented May 20, 2016

Hi

I found a very strange behaviour. My done callback was very often called twice. The problem is on the next line

} else if (action.length < 3) {

I am using babel and babel will transform next action

export function setAction(context, payload = {}, done) {
}

into the

function setAction(context) {
  var payload = arguments[1] || {};
  var done = arguments[2];
}

As you can see transformed action named setAction has just one parameter (original has 3 parameters) and your condition action.length < 3 will be equals true. I think that too many of us are using babel in this moment and can have a same problem.

@seeden seeden changed the title callAction has a bad condition callAction has a bad condition | bug May 20, 2016
@mridgway
Copy link
Collaborator

That's odd. Looks like this is the behavior of functions that use default parameters. Let me look in to whether this is new behavior from babel and whether we could treat this as a bug there, since it seems like babel shouldn't be changing the length.

@mridgway
Copy link
Collaborator

Opened https://phabricator.babeljs.io/T7377 to follow up with Babel team.

@mridgway
Copy link
Collaborator

After further investigation, this may be how ES6 spec works with default parameter values. We may have to find another solution for this internally.

@seeden
Copy link
Author

seeden commented May 22, 2016

yes, the current condition is not good

@mridgway
Copy link
Collaborator

So the only way to mitigate this that I can see is to check the return value against undefined. I'm not sure if there are valid cases where undefined could be the resolved value of the action's Promise. Seems like this would be a breaking change though either way.

@mridgway
Copy link
Collaborator

After finding a bug internally that was related to this arguments.length, I think the best way forward is to remove the automatic resolution of Promises by returning values from actions. Instead, we would require Promises to be explicitly returned from the action or we will wait for the done callback to be called.

Anyone using the return value as the resolved value would need to use return Promise.resolve(value) instead or just returning the value from the action.

@mridgway
Copy link
Collaborator

This would basically be just removing that line linked to in the origin comment (https://github.com/yahoo/fluxible/blob/master/packages/fluxible/utils/callAction.js#L29).

@carystanley
Copy link
Contributor

We do have actions without the callback param, that do not use promises, this is functionality that has been in place from the beginning. These actions are mostly doing synchronous logic and/or context.dispatch calls that would not really track callback, we have quite a few of these actions, so any breaking change introduced that removes support for this case would need substantial changes.

(just want you to be aware)

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

No branches or pull requests

3 participants